[libvirt PATCH v2 09/12] tools: support generating SEV secret injection tables
dovmurik at linux.ibm.com
Thu Oct 27 05:38:50 UTC 2022
On 26/10/2022 15:51, Daniel P. Berrangé wrote:
> On Wed, Oct 26, 2022 at 03:34:00PM +0300, Dov Murik wrote:
>> On 26/10/2022 12:59, Daniel P. Berrangé wrote:
>>> On Tue, Oct 25, 2022 at 07:38:43PM -0400, Cole Robinson wrote:
>>>> On 10/19/22 6:17 AM, Daniel P. Berrangé wrote:
>>> Reading cryttab(5) I see that /etc/crypttab supports an option
>>> called 'keyfile-size', which could be used to truncate the file.
>>> That's not at all user friendly for us, as the user pw data can be
>>> arbitrary length and when building the disk image template we
>>> don't know how many bytes are sensitive.IOW, we can't predict
>>> what keyfile-size to use.
>>> So it seems we have a few options
>>> 1. modify grub patches to remove the requirement for NUL
>>> 2. modify systemd to add a 'keyfile-nul-terminated' option
>>> to instruct it to stip a trailing NUL from key-file.
>>> 3. modify systemd to add a 'efi-secret=UUID' option and
>>> ignore key-file field entirely
>> Debian's crypttab supports keyscript=/path/to/script which should output
>> the passphrase to stdout. This is very generic and can allow us to:
>> 1. check a few GUIDs (fallback)
>> 2. drop terminating NUL
>> 3. for SNP-style late attestation: fetch attestation report, contact the KBS,
>> and retrieve the key (see AMD's example )
>>  https://github.com/AMDESE/sev-guest/tree/main/attestation/cryptsetup-initramfs
>> But there's no keyscript option in systemd...
> The keyfile path can, however, point to a AF_UNIX socket path.
> So you can have a script on the other end of the path that does
> anything at all. Still as per my earlier point, I find it very
> appealing to have a solution not reliant on us writing an
> extension script.
Credit should be given to James who insisted that the efi_secret kernel
module will expose a simple filesystem interface to read the secrets,
which allows using crypttab's keyfile without other changes. I think
this is the correct solution here.
BTW one more thing a scripted approach can do (maybe not with
keyscript=...) is unlink the coco/secrets/... file after cryptsetup
luksOpen. efi_secret module will then remove the file entry and wipe
the memory. This will prevent access to the disk passphrase (for
example if an attacker got root access to *read* arbitrary files); maybe
that's a security benefit. The downside is that it would prevent kexec
or re-opening the luks partition.
Aside, we can start thinking about initrd/cryptsetup for SNP/TDX
attestation + secret retrieval which require network support, crypto,
and more complex logic (which shouldn't be inside systemd). Maybe the
clevis people have a plan for the more complex key releases (where the
key is not simply a file).
More information about the libvir-list