Messages in this thread | | | Date | Mon, 8 Aug 2022 16:32:31 -0500 | Subject | Re: [PATCH Part2 v6 17/49] crypto: ccp: Add the SNP_{SET,GET}_EXT_CONFIG command | From | Tom Lendacky <> |
| |
On 8/8/22 14:27, Dionna Amalie Glaze wrote: > To preface, I don't want to delay this patch set, only have the > conversation at the most appropriate place. > >> >>> The SEV-SNP firmware provides the SNP_CONFIG command used to set the >>> system-wide configuration value for SNP guests. The information includes >>> the TCB version string to be reported in guest attestation reports. >> > > The system-wide aspect of this makes me wonder if we can also have a > VM instance-specific extension. This is important for the use case > that we may see secure boot variables included in the launch > measurement, making offline signing of the UEFI image impossible. We > can't sign the cross-product of all UEFI builds and every user's EFI > variables. We'd like to include an instance-specific certificate that > specifies the platform-endorsed golden measurement of the UEFI. > > An alternative that doesn't require a change to the kernel is to just > make this certificate fetchable from a FAMILY_ID-keyed, predetermined > URL prefix + IMAGE_ID + '.crt', but this requires a download (and > continuous hosting) to do something as routine as collecting an > attestation report. It's up to the upstream community to determine if > that is an acceptable cost to keep the complexity of a certificate > table merge operation out of the kernel. > > The SNP API specification gives an interpretation to the data blob
That's the GHCB specification, not the SNP API.
> here as a table of GUID/offset pairs followed by data blobs that > presumably are at the appropriate offsets into the data pages. The > spec allows for the host to add any number of GUID/offset pairs it > wants, with 3 specific GUIDs recommended for the AMD PSP certificate > chain. > > The snp_guest_ext_guest_request function in ccp is what passes back > the certificate data that was previously stored, so I'm wondering if > it can take an extra (pointer,len) pair of VM instance certificate > data to merge with the host certificate data before returning to the > guest. The new required length is the sum total of both the header > certs and instance certs. The operation to copy the data is no longer > a memcpy but a header merge that tracks the offset shifts caused by a > larger header and other certificates in the remaining data pages. > > I can propose my own patch on top of this v6 patch set that adds a KVM > ioctl like KVM_{GET,SET}_INSTANCE_SNP_EXT_CONFIG and then pass along
Would it be burden to supply all the certificates, both system and per-VM, in this KVM call? On the SNP Extended Guest Request, the hypervisor could just check if there is a per-VM blob and return that or else return the system-wide blob (if present).
Thanks, Tom
> the stored certificate blob in the request call. I'd prefer to have > the design agreed upon upfront though. >
| |