Re: [libvirt PATCH v2 09/12] tools: support generating SEV secret injection tables
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-init...
>
> 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