Re: [libvirt] [PATCH 1/9] Add volume encryption information handling.

Friday, 24 July 2009

----- "Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote:
...
 For the domain XML I agree that libirt would not need to worry about
 multiple LUKS keys, but for the storage volume XML we would need to 
 expose the fact that there are multiple keys,or allow creation of
 volumes with multiple keys. I don't know.  Does a fact that a feature exist
imply that libvirt must fully expose it?  Any use case for multiple LUKS passphrases I can
think of is a bit far-fetched.

...
 > We know that the type and amount of information that will need
to be
 > stored will vary depending on the "encryption format"; on the other
 > hand, expecting that the information consists of independent "secrets",
 > each with a simple and format-independent definition, is probably too
 > optimistic.  (As mentioned above, we might need a key slot ID associated
 > with a LUKS passphrase; we might also need a password hash algorithm
 > associated with a dm-crypt passphrase.  The encryption formats used in
 > practice are often complex enough that a "simple passphrase" can not
 > be used.)  Once we have to assume that each secret can have an "encryption
 > format"-dependent format, I think it is much clearer to use something like

 The idea of a 'key slot' and 'password hash algorithm' are not
neccessarily
 unique to LUKS though. No, but the specific semantics and value ranges are very
likely to be different across formats.

...
 If we get 2 different encryption formats both requiring
 the concept of a 'key slot' we need to represent them in the same way in the
 XML, not hve a different XML for each format.  I was arguing about making the
internal representation format-specific, not the XML.

In the XML, having something like <secret type='...' id='...'> and
<parameter name='...' id='...'> is quite reasonable.

I think this is not the case in the internal representation - the information will
eventually have to be "parsed" into format-specific variables, and it seems
better to me to do this at once from the XML, than to create an additional internal
representation and additionl "parsing" code.

<snip>

...
 The libvirt approach to XML representation is to try and define XML
format
 that are indenpedant of specific implementations. This does imply that the
 XML parser cannot really do anything beyond basic syntactic validation,
 near zero semantic  validation. The task of semantic validation of the
 parsed data, is thus passed off to the internal drivers which provide the
 specific implementations.  Not having any driver-specific knowledge in the generic
parser does make sense; I'll change the code.
    Mirek

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005