[PATCH v8 0/4] Allow guest access to EFI confidential computing secret area

Borislav Petkov bp at suse.de
Tue Mar 29 18:30:15 UTC 2022


Hi Dov,

On Tue, Mar 29, 2022 at 03:55:38PM +0300, Dov Murik wrote:
> Let's see if I understand this correctly:
> 
> You want the guest to know if the its own SEV VM policy allows
> debugging.  And that flag has to be trusted -- so passed from the Guest
> Owner in a secure channel (otherwise the host could set it to
> ALLOW_DEBUGGING even though the Guest Owner didn't approve that).

Yeah, and then dump all the guest memory and thus bypass the whole
memory encryption fun. So yeah, it should be encrypted and accessible
only to the guest and supplied by the guest owner.

> The SEV launch secrets area can also be read by grub [1], for example,
> to fetch a luks passphrase from there (instead of from keyboard).
> That's why its structure is generic.

Ok, fair enough.

> I think Guest Owner can add a 1-byte predefined secret to the SEV secret
> table, let's say an entry with GUID 2b91a212-b0e1-4816-b021-1e9991ddb6af
> and value "\x01" to indicate debugging is allowed.
> 
> With the efi_secrets module, a 1-byte file called
> /sys/kernel/security/secrets/coco/2b91a212-b0e1-4816-b021-1e9991ddb6af

I'd love it if that were more user-friendly:

/sys/kernel/security/secrets/coco/attributes

and there's:

debugging:1
...

and others.

> will appear with "\x01" in its content.
> 
> This can indicate to the guest that debugging was permitted by the Guest
> Owner.

But yeah, that should be the gist of the functionality.

> If you want this unified in the kernel, maybe we can look for this entry
> and set the relevant kernel variable.

So now that I think of it, it would be even nicer if the fact whether
guest debugging is allowed, were available to the guest *very early*
during boot. Because I think the most important cases where you'd want
to singlestep a SEV* guest with the qemu gdbstub is early guest kernel
boot code. So it would be cool if we'd have access to the debugging
setting that early.

Lemme have a look at your patches in detail to get an idea what's
happening there.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg



More information about the Linux-security-module-archive mailing list