Hello Boris, On 24/03/2022 18:33, Borislav Petkov wrote: > On Mon, Feb 28, 2022 at 11:42:50AM +0000, Dov Murik wrote: >> Confidential computing (coco) hardware such as AMD SEV (Secure Encrypted >> Virtualization) allows guest owners to inject secrets into the VMs >> memory without the host/hypervisor being able to read them. In SEV, >> secret injection is performed early in the VM launch process, before the >> guest starts running. >> >> OVMF already reserves designated area for secret injection (in its >> AmdSev package; see edk2 commit 01726b6d23d4 "OvmfPkg/AmdSev: Expose the >> Sev Secret area using a configuration table" [1]), but the secrets were >> not available in the guest kernel. >> >> The patch series keeps the address of the EFI-provided memory for >> injected secrets, and exposes the secrets to userspace via securityfs >> using a new efi_secret kernel module. The module is autoloaded (by the >> EFI driver) if the secret area is populated. > > Right, so this thing. > > Tom and I were talking about SEV* guest debugging today and I believe > there might be another use case for this: SEV-ES guests cannot find out > from an attestation report - like SNP guests can - whether they're being > debugged or not so it would be very helpful if the fact that a -ES guest > is being debugged, could be supplied through such a secrets blob. > > Because then, when I'm singlestepping the guest with gdb over the > gdbstub, the guest could determine based on those guest-owner previously > injected secrets whether it should allow debugging or not. > 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). > And this is where your set comes in. > > However, I'm wondering if - instead of defining your own secrets structs > etc - you could use the SNP confidential computing blob machinery the > SNP set is adding. In particular: > > https://lore.kernel.org/all/20220307213356.2797205-30-brijesh.singh@xxxxxxx/ > > And you're adding another GUID but maybe you could simply use the SNP > thing called EFI_CC_BLOB_GUID and mimick that layout. > > That should unify things more. And then guest kernel code could query > the blob also for debugging policy and so on. > Maybe you could do that, but that will unify things that are not the same, so I think it is the wrong approach here. The SNP secrets are secrets generated by the AMD-SP and allow the guest to communicate with the PSP. There are exactly 4 of them (if I remember correctly) and they are only AES-256-GCM keys (if I remember correctly). On the other hand, the SEV launch secrets (which this series is about) are secrets populated by the Guest Owner and are intended for the proper operation of the applications in the guest (example use cases: luks passphrase, secret API keys, file decryption keys, encrypted container images keys, ...). 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. [1] https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00066.html > Thoughts, opinions? > 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 will appear with "\x01" in its content. This can indicate to the guest that debugging was permitted by the Guest Owner. If you want this unified in the kernel, maybe we can look for this entry and set the relevant kernel variable. -Dov
