On Wed, 2023-05-03 at 08:24 -0700, Dionna Amalie Glaze wrote: > On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@xxxxxxx> wrote: [...] > > If there is still a strong desire to have COCONUT with a TPM > > (running at CPL-0) before CPL-3 support is usable, then I can live > > with including code for that as a temporary solution. But linking > > huge amounts of C code (like openssl or a tpm lib) into the SVSM > > rust binary kind of contradicts the goals which made us using Rust > > for project in the first place. That is why I only see this as a > > temporary solution. > > > > > Since we don't want to split resources or have competing > > > projects, we are leaning towards moving our development resources > > > over to the coconut-svsm project. > > > > Not to throw a wrench in the works, but is it possible for us to have > an RTMR protocol as a stop-gap between a fully paravirtualized vTPM > and a fully internalized vTPM? The EFI protocol > CC_MEASUREMENT_PROTOCOL is already standardized, and it can serve as > a hardware-rooted integrity measure for a paravirtualized vTPM. This > solution would further allow a TDX measured boot solution to be more > thoroughly supported earlier, given that we'd need to have the RTMR > event log replay logic implemented. >From our point of view, having a large set of existing open source tools which speak the TPM protocol is the big benefit of the vTPM approach. Currently the partially closed source Amber attestation service, which is designed as the recipient of the RTMR protocol, only understands TDX (and SGX) attestation, so it would be more work than simply implementing a RTMR approach to make it attach to this tool. There would also be the huge problem of how we replicate the quoting enclave on SEV... James
