[ add Dan Middleton for his awareness ] Dionna Amalie Glaze wrote: > > > So we're sort of complicating the more common case to support a more niche > > > one (as far as userspace is concerned anyway; as far as kernel goes, your > > > approach is certainly simplest :)). > > > > > > Instead, maybe a compromise is warranted so the requirements on userspace > > > side are less complicated for a more basic deployment: > > > > > > 1) If /dev/sev is used to set a global certificate, then that will be > > > used unconditionally by KVM, protected by simple dumb mutex during > > > usage/update. > > > 2) If /dev/sev is not used to set the global certificate is the value > > > is NULL, we assume userspace wants full responsibility for managing > > > certificates and exit to userspace to request the certs in the manner > > > you suggested. > > > > > > Sean, Dionna, would this cover your concerns and address the certificate > > > update use-case? > > > > Honestly, no. I see zero reason for the kernel to be involved. IIUC, there's no > > privileged operations that require kernel intervention, which means that shoving > > a global cert into /dev/sev is using the CCP driver as middleman. Just use a > > userspace daemon. I have a very hard time believing that passing around large-ish > > blobs of data in userspace isn't already a solved problem. > > ping sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx and +Dan Williams Apologies Dionna, I missed this earlier. > > I think for a uniform experience for all coco technologies, we need > someone from Intel to weigh in on supporting auxblob through a similar > vmexit. Whereas the quoting enclave gets its PCK cert installed by the > host, something like the firmware's SBOM [1] could be delivered in > auxblob. The proposal to embed the compressed SBOM binary in a coff > section of the UEFI doesn't get it communicated to user space, so this > is a good place to get that info about the expected TDMR in. The SBOM > proposal itself would need additional modeling in the coRIM profile to > have extra coco-specific measurements or we need to find some other > method of getting this info bundled with the attestation report. SBOM looks different than the SEV use case of @auxblob to convey a certificate chain. Are you asking for @auxblob to be SBOM on TDX and a certchain on SEV, or unifying the @auxblob format on SBOM? > My own plan for SEV-SNP was to have a bespoke signed measurement of > the UEFI in the GUID table, but that doesn't extend to TDX. If we're > looking more at an industry alignment on coRIM for SBOM formats (yes > please), then it'd be great to start getting that kind of info plumbed > to the user in a uniform way that doesn't have to rely on servers > providing the endorsements. > > [1] https://uefi.org/blog/firmware-sbom-proposal Honestly my first reaction for this ABI would be for a new file under /sys/firmware/efi/efivars or similar.
