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

[James Bottomley <jejb@linux.ibm.com>]

On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote:
> On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky 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.

OK, so this, for IBM, is directly necessary.  We have the vTPM pull
request about ready to go and we'll probably send it still to the AMD
SVSM.  Given that the AMD SVSM already has the openssl library and the
attestation report support, do you want to pull them into coconut
directly so we can base a coconut vTPM pull request on that?

> 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.

Crypto support in ring-0 is unavoidable if we want to retain control of
the VMPCK0 key in ring-0.  I can't see us giving it to ring-3 because
that would give up control of the SVSM identity and basically make the
ring-0 separation useless because you can compromise ring-3 and get the
key and then communicate with the PSP as the SVSM.

I think the above problem also indicates no-one really has a fully
thought out security model that shows practically how ring-3 improves
the security posture.  So I really think starting in ring-0 and then
moving pieces to ring-3 and discussing whether this materially improves
the security posture based on the code and how it operates gets us
around the lack of understanding of the security model because we
proceed by evolution.

The next question that's going to arise is *where* the crypto libraries
should reside.  Given they're somewhat large, duplicating them for
every cpl-3 application plus cpl-3 seems wasteful, so some type of vdso
model sounds better (and might work instead of a syscall interfaces for
cpl-0 services that are pure code).  

> 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

Well, depending on how you order them, possibly.  The vTPM has a simple
request/response model, so it really doesn't have much need of a
scheduler for instance.  And we could obviously bring up cpl-3 before a
module loader/ram filesystem and move to that later.

> 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'm not sure it will be.  If some cloud or distro wants to shoot for
FIPS compliance of the SVSM, for instance, a requirement will likely be
to use a FIPS certified crypto library ... and they're all currently in
C.  That's not to say we shouldn't aim for minimizing the C
dependencies, but I don't see a "pure rust or else" approach
facilitating the initial utility of the project.

James