[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v4 12/18] qcow2: extend specification to cover L
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-block] [PATCH v4 12/18] qcow2: extend specification to cover LUKS encryption |
Date: |
Wed, 15 Feb 2017 16:18:37 +0100 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Fri 10 Feb 2017 06:09:04 PM CET, Daniel P. Berrange wrote:
> Update the qcow2 specification to describe how the LUKS header is
> placed inside a qcow2 file, when using LUKS encryption for the
> qcow2 payload instead of the legacy AES-CBC encryption
>
> Reviewed-by: Max Reitz <address@hidden>
> Signed-off-by: Daniel P. Berrange <address@hidden>
> + Byte 0 - 7: Offset into the image file at which the encryption
> + header starts in bytes. Must be aligned to a cluster
> + boundary.
> + Byte 8 - 15: Length of the written encryption header in bytes.
> + Note actual space allocated in the qcow2 file may
> + be larger than this value, since it will be rounded
> + to the nearest multiple of the cluster size. Any
> + unused bytes in the allocated space will be initialized
> + to 0.
You are using tabs instead of spaces in these paragraphs. Those are the
only tabs in the whole file so you probably want to change them.
> +In the LUKS partition header, the "payload-offset" field will be
> +calculated as normal for the LUKS spec. ie the size of the LUKS
> +header, plus key material regions, plus padding. Its value is not
> +used, however, since the qcow2 file format itself defines where
> +the real payload offset is.
If I understand this, the value of payload-offset is not used but it
must be correct.
Is payload-offset also relative to the start of the LUKS header? I
assume that it is, but maybe it can be clarified like you did with
key-material-offset.
> +In the LUKS key slots header, the "key-material-offset" is relative
> +to the start of the LUKS header clusters in the qcow2 container,
> +not the start of the qcow2 file.
Berto
- [Qemu-block] [PATCH v4 04/18] qcow: require image size to be > 1 for new images, (continued)
- [Qemu-block] [PATCH v4 04/18] qcow: require image size to be > 1 for new images, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 05/18] iotests: skip 042 with qcow which dosn't support zero sized images, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 06/18] iotests: skip 048 with qcow which doesn't support resize, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 07/18] iotests: fix 097 when run with qcow, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 08/18] qcow: make encrypt_sectors encrypt in place, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 09/18] qcow: convert QCow to use QCryptoBlock for encryption, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 10/18] qcow2: make qcow2_encrypt_sectors encrypt in place, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 12/18] qcow2: extend specification to cover LUKS encryption, Daniel P. Berrange, 2017/02/10
- Re: [Qemu-block] [PATCH v4 12/18] qcow2: extend specification to cover LUKS encryption,
Alberto Garcia <=
- [Qemu-block] [PATCH v4 11/18] qcow2: convert QCow2 to use QCryptoBlock for encryption, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 15/18] iotests: enable tests 134 and 158 to work with qcow (v1), Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 14/18] qcow2: add iotests to cover LUKS encryption support, Daniel P. Berrange, 2017/02/10
- [Qemu-block] [PATCH v4 13/18] qcow2: add support for LUKS encryption format, Daniel P. Berrange, 2017/02/10