On Wed, May 03, 2023 at 08:24:10AM -0700, Dionna Amalie Glaze wrote: > On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@xxxxxxx> wrote: > > > - On the subject of priorities, the number one priority for the > > > linux-svsm project has been to quickly achieve production quality vTPM > > > support. The support for this is being actively worked on by > > > linux-svsm contributors and we'd want to find fastest path towards > > > getting that redirected into coconut-svsm (possibly starting with CPL0 > > > implementation until CPL3 support is available) and the project > > > hardened for a release. I imagine there will be some competing > > > priorities from coconut-svsm project currently, so wanted to get this > > > out on the table from the beginning. > > > > That has been under discussion for some time, and honestly I think > > the approach taken is the main difference between linux-svsm and > > COCONUT. My position here is, and that comes with a big 'BUT', that I am > > not fundamentally opposed to having a temporary solution for the TPM > > until CPL-3 support is at a point where it can run a TPM module. > > > > And here come the 'BUT': Since the goal of having one project is to > > bundle community efforts, I think that the joint efforts are better > > targeted at getting CPL-3 support to a point where it can run modules. > > On that side some input and help is needed, especially to define the > > syscall interface so that it suits the needs of a TPM implementation. > > > > It is also not the case that CPL-3 support is out more than a year or > > so. The RamFS is almost ready, as is the archive file inclusion[1]. We > > will move to task management next, the goal is still to have basic > > support ready in 2H2023. > > > > [1] https://github.com/coconut-svsm/svsm/pull/27 > > > > 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. IMHO it would be preferrable if RTMR was exposed to as little as possible. The less special cases we have to build into applications / projects related to confidential virt, the better off we'll be. The use of industry standard TPMs with PCRs reduces the matrix that work that is needed to support confidential virt across the stack. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
