On Wed, Jan 13, 2016 at 04:47:47PM -0700, Eric Blake wrote:
> On 01/12/2016 11:56 AM, Daniel P. Berrange wrote:
> > Add a block driver that is capable of supporting any full disk
> > encryption format. This utilizes the previously added block
> > encryption code, and at this time supports the LUKS format.
> >
> > The driver code is capable of supporting any format supported
> > by the QCryptoBlock module, so it registers one block driver
> > for each format.
> >
> > At this time, the "luks" driver is registered. New LUKS
> > compatible volume can be formatted using qemu-img
> >
> > $ qemu-img create --object secret,data=123456,id=sec0 \
> > -f luks -o key-id=sec0,cipher-alg=aes-256,\
> > cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \
> > demo.luks 10G
> >
>
> > @@ -1664,6 +1664,21 @@
> > 'data': { 'file': 'BlockdevRef' } }
> >
> > ##
> > +# @BlockdevOptionsLUKS
> > +#
> > +# Driver specific block device options for LUKS.
> > +#
> > +# @key-id: #optional the ID of a QCryptoSecret object providing
> > +# the decryption key (since 2.6)
> > +#
> > +# Since: 2.6
> > +##
> > +{ 'struct': 'BlockdevOptionsLUKS',
> > + 'base': 'BlockdevOptionsGenericFormat',
> > + 'data': { '*key-id': 'str' } }
>
> And if key-id is omitted, how does it work?
You can only omit it if using BDRV_O_NO_IO, which is used by qemu-img info
to report info about the disk without needing to decrypt any payload.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
