qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 13/20] qcow2: add support for LUKS encryption


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v9 13/20] qcow2: add support for LUKS encryption format
Date: Wed, 21 Jun 2017 16:59:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 2017-06-21 16:46, Max Reitz wrote:
> On 2017-06-21 16:42, Max Reitz wrote:
>> On 2017-06-19 19:34, Daniel P. Berrange wrote:
>>> This adds support for using LUKS as an encryption format
>>> with the qcow2 file, using the new encrypt.format parameter
>>> to request "luks" format. e.g.
>>>
>>>   # qemu-img create --object secret,data=123456,id=sec0 \
>>>        -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \
>>>        test.qcow2 10G
>>>
>>> The legacy "encryption=on" parameter still results in
>>> creation of the old qcow2 AES format (and is equivalent
>>> to the new 'encryption-format=aes'). e.g. the following are
>>> equivalent:
>>>
>>>   # qemu-img create --object secret,data=123456,id=sec0 \
>>>        -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \
>>>        test.qcow2 10G
>>>
>>>  # qemu-img create --object secret,data=123456,id=sec0 \
>>>        -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \
>>>        test.qcow2 10G
>>>
>>> With the LUKS format it is necessary to store the LUKS
>>> partition header and key material in the QCow2 file. This
>>> data can be many MB in size, so cannot go into the QCow2
>>> header region directly. Thus the spec defines a FDE
>>> (Full Disk Encryption) header extension that specifies
>>> the offset of a set of clusters to hold the FDE headers,
>>> as well as the length of that region. The LUKS header is
>>> thus stored in these extra allocated clusters before the
>>> main image payload.
>>>
>>> Aside from all the cryptographic differences implied by
>>> use of the LUKS format, there is one further key difference
>>> between the use of legacy AES and LUKS encryption in qcow2.
>>> For LUKS, the initialiazation vectors are generated using
>>> the host physical sector as the input, rather than the
>>> guest virtual sector. This guarantees unique initialization
>>> vectors for all sectors when qcow2 internal snapshots are
>>> used, thus giving stronger protection against watermarking
>>> attacks.
>>>
>>> Reviewed-by: Eric Blake <address@hidden>
>>> Reviewed-by: Alberto Garcia <address@hidden>
>>> Signed-off-by: Daniel P. Berrange <address@hidden>
>>> ---
>>>  block/qcow2-cluster.c      |   4 +-
>>>  block/qcow2-refcount.c     |  10 ++
>>>  block/qcow2.c              | 268 
>>> ++++++++++++++++++++++++++++++++++++++------
>>>  block/qcow2.h              |   9 ++
>>>  qapi/block-core.json       |   5 +-
>>>  tests/qemu-iotests/082.out | 270 
>>> ++++++++++++++++++++++++++++++++++++---------
>>>  6 files changed, 478 insertions(+), 88 deletions(-)
>>
>> Reviewed-by: Max Reitz <address@hidden>
> 
> (But due to the split of do_perform_cow(), this will need the same
> changes that patch 10 and 11 will need (in this case only contextual, in
> the cases of 10 and 11 there are also functional changes required).)

(Turns out it will need a functional change, too, because
do_perform_cow_encrypt() doesn't take the host offset yet.)

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]