Re: [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface

From: Max Reitz <mreitz@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface
Date: Fri, 4 Oct 2019 21:10:52 +0200	[thread overview]
Message-ID: <fb2cd2e0-2718-215f-d6af-59b64b229b4f@redhat.com> (raw)
In-Reply-To: <20190912223028.18496-1-mlevitsk@redhat.com>

[-- Attachment #1.1: Type: text/plain, Size: 1033 bytes --]

On 13.09.19 00:30, Maxim Levitsky wrote:
> This patch series is continuation of my work to add encryption
> key managment to luks/qcow2 with luks.
> 
> This is second version of this patch set.
> The changes are mostly addressing the review feedback,
> plus I tested (and fixed sadly) the somewhat ugly code
> that allows to still write share a raw luks device,
> while preveting the key managment from happening in this case,
> as it is unsafe.
> I added a new iotest dedicated to that as well.
> 
> Best regards,
> 	Maxim Levitsky

At least for an RFC looks good from my perspective.  I didn’t look at
the crypto things very closely (assuming Dan would do so), and I didn’t
check the iotests in detail.  (But it definitely doesn’t look like they
lack in breadth.  Maybe I’d like to see a test that you cannot have
other useful nodes attached to the LUKS or qcow2 node while the
amendment process is ongoing (because CONSISTENT_READ is unshared).  But
that’s the only thing I can think of.)

Max

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]