[libvirt PATCH v2 09/12] tools: support generating SEV secret injection tables

[Dov Murik]

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
>>>     termination
>>>  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 [1])
>>
>> [1] 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).

-Dov