Re: [libvirt] [PATCH 1/9] Add volume encryption information handling.
----- "Daniel P. Berrange" <berrange(a)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