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

[Miloslav Trmac]

----- "Daniel P. Berrange" <berrange at redhat.com> 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