Block Crypto Driver

The block crypto driver provides support for full disk encryption at the block layer. At time of writing it supports the LUKSv1 format.

To Do List

Secure header erase

Traditionally an application will merely delete a volume when it is done with it. For file based images this newly created images will never be able to see this previous data since file extents are always initialized to zero, but it is still visible in the underlying block storage device until the sectors are overwritten. For block based images (SCSI, LVM, NBD, iSCSI, RBD, etc) there are no guarantees in general that data from the block device will not be visible to future block devices that are created.

Applications could mitigate these risks by explicitly writing zeros across the entire image before deleting it, however, even this is not guaranteed to purge data, as storage devices don't all guarantee that the same underlying sectors are used when data is rewritten. Some devices provide a "secure erase" feature that can avoid this remapping and guarantee erase of original data. Wiping the whole image is also potentially inefficient because for formats like LUKSv1, in practice it is sufficient to just erase the key material stored in the image header

Applications using QEMU should not need to understand specifics about the encryption format, so should not be expected to figure out which region of disk they need to wipe to purge key material. This there is a need to extent the block layer with a "secure erase" feature to allow safe deletion of encrypted volumes.

Password management

Some disk formats such as LUKSv1 support multiple user passwords to unlock the device. The current impl only supports a single password in slot0 and does not provide a way to change it. There needs to be a block layer API feature to allow passwords to be added / removed from arbitrary slots. This indirectly allows for password changes by adding a new password and then subsequently removing the old password. This is preferrable to an in-place password change since it avoids risk of loosing access to encrypted data, if an I/O error occurrs half way through updating the existing password on disk.

Creationg with non-raw files

Currently the LUKSv1 driver supports the bdrv_create operation, which creates an raw file and then formats a LUKS volume into it. The block driver creation API does not provide a way to specify anything other than a plain filename when creating a new volume. This means it is not possible, for example, to create a RBD volume and then format it with LUKS in one single operation.

The volume creation API in the block layer needs to be extended to allow the full block driver syntax to be specified, so arbitrary block drivers can be nested at time of creation

Formatting on existing volumes

Currently the LUKSv1 driver supports the bdrv_create operation, which creates an raw file and then formats a LUKS volume into it. If there is already a pre-existing volume it is not possible to then format this with LUKS. This means it is not possible, for example, to create an RBD volume out of band, and then format it with LUKS separately.

The block layer would need to be extended to grow a 'bdrv_format' operation. This would accept a set of block opts for new LUKS format, and a second set of block opts for the underlying pre-existnig volume