[ add Ard for the SBOM sysfs ABI commentary ] Dionna Amalie Glaze wrote: [..] > > > 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. > > For UEFI specifically that could make sense, yes. Not everyone has > been mounting efivars, so it's been a bit of an uphill battle for that > one. I wonder what the concern is with mounting efivarfs vs configfs? In any event this seems distinct enough to be its own /sys/firmware/efi/sbom file. I would defer to Ard, but I think SBOM is a generally useful concept that would be out of place as a blob returned from configfs-tsm. > Still there's the matter of cached TDI RIMs. NVIDIA would have I am not immediatly sure what a "TDI RIM" is? > everyone send attestation requests to their servers every quote > request in the NRAS architecture, but we're looking at other ways to "NRAS" does not parse for me either. > provide reliable attestation without a third party service, albeit > with slightly different security properties. Setting the above confusion aside, I would just say that in general yes, the kernel needs to understand its role in an end-to-end attestation architecture that is not beholden to a single vendor, but also allows the kernel to enforce ABI stability / mitigate regressions based on binary format changes.
