| Message ID | 20220228114254.1099945-1-dovmurik@linux.ibm.com |
|---|---|
| Headers | show |
| Series | Allow guest access to EFI confidential computing secret area | expand |
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. 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@amd.com/ 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. Thoughts, opinions?
On 29/03/2022 21:30, Borislav Petkov wrote: > > 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. Is efi_config_parse_tables() early enough? That's where we learn for the first time that the firmware has a launch-secrets area that we can look at. We can add there (say, next to the call to efi_tpm_eventlog_init()) a code to: 1. map the secret area (ioremap_encrypted()) 2. parse the table, look for the "sev debug enabled" GUID. 3. set the value of the kernel variable that we can later use anywhere. Of course Ard might know about a better mechanism or place to do that. -Dov
On Wed, Mar 30, 2022 at 09:11:54AM +0300, Dov Murik wrote: > If that's the case, we don't need a secure channel and secret injection. > You can use a simple "sev=debug" (or whatever) in the kernel > command-line to indicate your needs. Yeah, that would work for a normal SEV guest. However, if it is an -ES guest, you need to somehow tell it as the guest owner: "hey you're being debugged and that's fine." Because if you want to singlestep the thing, you're going to land in the #VC handler and destroy registers so you want to save them first if you're being debugged and then shovel them out to the host somehow. And that's another question but first things first. And "if you're being debugged" needs to be somehow told the guest through a secure channel so that the HV doesn't go and simply enable debugging by booting with "sev=debug" and bypass it all. And SNP has access to the policy in the attestation report, says Tom, so that's possible there. So we need a way to add the debugging aspect to the measurement and be able to recreate that measurement quickly so that a simple debugging session of a kernel in a guest can work pretty much the same with a SEV* guest. I'm still digging the details tho...
On 31/03/2022 12:19, Borislav Petkov wrote: > On Wed, Mar 30, 2022 at 09:11:54AM +0300, Dov Murik wrote: >> If that's the case, we don't need a secure channel and secret injection. >> You can use a simple "sev=debug" (or whatever) in the kernel >> command-line to indicate your needs. > > Yeah, that would work for a normal SEV guest. > > However, if it is an -ES guest, you need to somehow tell it as the guest > owner: "hey you're being debugged and that's fine." > > Because if you want to singlestep the thing, you're going to land in > the #VC handler and destroy registers so you want to save them first if > you're being debugged and then shovel them out to the host somehow. And > that's another question but first things first. > > And "if you're being debugged" needs to be somehow told the guest > through a secure channel so that the HV doesn't go and simply enable > debugging by booting with "sev=debug" and bypass it all. > Note that the HV can also start the VM with SEV completely turned off. Similarly, it can enable debugging and "fool" the guest. Of course all this tricks will affect the measurement, and then the Guest Owner will know that something is wrong and won't inject the secrets. If you don't rely on secret injection anyway, then I think a kernel command-line param is good enough. (I might be missing a scenario though) Maybe you can use KVM_SEV_GET_ATTESTATION_REPORT (ask the host to do it for you). But I think it returns only the launch digest, and you can't figure out the SEV Policy field from it. > And SNP has access to the policy in the attestation report, says Tom, so > that's possible there. True. But not in really early boot? This is all in the sev-guest platform driver. > > So we need a way to add the debugging aspect to the measurement and be > able to recreate that measurement quickly so that a simple debugging > session of a kernel in a guest can work pretty much the same with a SEV* > guest. > > I'm still digging the details tho... >