qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v10 00/20] Convert QCow[2] to QCryptoBlock & add


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v10 00/20] Convert QCow[2] to QCryptoBlock & add LUKS support
Date: Mon, 26 Jun 2017 21:20:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 2017-06-23 18:23, Daniel P. Berrange wrote:
> Previously posted:
> 
>  v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00201.html
>  v2: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05147.html
>  v3: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05671.html
>  v4: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg02293.html
>  v5: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04653.html
>  v6: https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04561.html
>  v7: https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg05818.html
>  v8: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg00308.html
>  v9: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg04250.html
> 
> Patches 7, 10, 11 & 13 have changes needing new R-b tags since previous
> postings
> 
> This series is a continuation of previous work to support LUKS in
> QEMU. The existing merged code supports LUKS as a standalone
> driver which can be layered over/under any other QEMU block device
> driver. This works well when using LUKS over protocol drivers (file,
> rbd, iscsi, etc, etc), but has some downsides when combined with
> format drivers like qcow2.
> 
> If you layer LUKS under qcow2 (eg qcow2 -> luks -> file) then you
> cannot get any information about the qcow2 file without first
> decrypting it, as both the header and payload are encrypted.
> 
> If you layer LUKS over qcow2 (eg luks -> qcow2 -> file) then you
> cannot distinguish between a qcow2 file where the guest has done
> LUKS encryption from a qcow2 file which qemu has done encryption.
> More seriously, when encrypting sectors the guest virtual sector
> is used as the input for deriving the initialization vectors.
> When internal snapshots are used, this means that multiple sectors
> in the qcow2 file may be encrypted with the same initialization
> vector. This is a security weakness when combined with certain
> cryptographic modes.
> 
> Integrating LUKS natively into qcow2 allows us to combine the
> best aspects of both layering strategies above. In particular
> the header remains unecrypted, but initialization vectors are
> generated using physical sector numbers preserving security
> when snapshots are used. This is a change from previous postings
> of this work, where the IVs were (incorrectly) generated based
> on the virtual disk sector.
> 
> In a previous posting of this work, Fam had suggested that we
> do integration by layering luks over qcow2, but having QEMU
> block layer automatically create the luks driver above qcow2
> based on the qcow2 header crypt_method field. This is not
> possible though, because such a scheme would suffer from the
> problem of IVs being generated from the virtual disk sector
> instead of physical disk sector. So having LUKS specific
> code in the qcow2 block driver is unavoidable. In comparison
> to the previous posting though, the amount of code in qcow2.c
> has been reduced by allowing re-use of code from block/crypto.c
> for handling QemuOpts -> QAPI conversion. So extra lines of
> code in qcow2 to support LUKS is < 200.
> 
> I have also split the changes to qcow2 up into 2 patches. The
> first patch simply introduces use of the QCryptoBlock framework
> to qcow2 for the existing (deprecated) AES-CBC encryption method.
> The second patch wires up the LUKS support for qcow2. This makes
> it clearer which parts of the changes are related to plain code
> refactoring, vs enabling the new features. Specifically we can
> now see that the LUKS enablement in qcow2 has this footprint:

Thanks, fixed the secret objects (s/filename/file/) in the commit
message, made patch 12 to point to docs/interop/qcow2.txt (where the
spec has been moved to recently) and applied the series to my block branch:

https://github.com/XanClic/qemu/commits/block

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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