Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP

[Claudio Carvalho <cclaudio@linux.ibm.com>]

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