Hi Jorg, On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote: > > > - Are you open to having maintainers outside of SUSE? There is some > > linux-svsm community concern about project governance and project > > priorities and release schedules. This wouldn't have to be AMD even, > > but we'd volunteer to help here if desired, but we'd like to foster a > > true community model for governance regardless. We'd love to hear > > thoughts on this from coconut-svsm folks. > > Yes, I am definitely willing to make the project more open and move to a > maintainer-group model, no intention from my side to become a BDFL for > the project. I just have no clear picture yet how the model should look > like and how to get there. I will send a separate email to kick-start a > discussion about that. > Thanks. I would be happy to collaborate in that discussion. > > - 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. > > I think the crypto support requires more design discussion since it is required in multiple places. The experience I've had adding SVSM-vTPM support is that the SVSM needs crypto for requesting an attestation report (SNP_GUEST_REQUEST messages sent to the security processor PSP have to be encrypted with AES_GCM) and the vTPM also needs crypto for the TPM crypto operations. We could just duplicate the crypto library, or find a way to share it (e.g. vdso approach). For the SVSM, it would be rust code talking to the crypto library; for the vTPM it would be the vTPM (most likely an existing C implementation) talking to the crypto library. Regards, Claudio
