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

[Dionna Amalie Glaze <dionnaglaze@google.com>]

On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@suse.de> wrote:
>
> Hi Tom,
>
> thanks for that comparision!
>
> On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote:
> > While both SVSM implementations use the Qemu Firmware Configuration
> > (fw_cfg) interface, the coconut-svsm relies on it a bit more than
> > linux-svsm. In either case, other interfaces may need to be supported in
> > order for an SVSM to work with a VMM other than Qemu.
>
> Right, that is something I have been thinking about. After I talked to a
> few others about it, I came to the conclusion that neither COCONUT nor
> linux-svsm use an optimal interface to request information from the HV.
> I think it would be best if we move to a model where the MADT and E820
> tables from QEMU (or any other HV) are part of the measured initial
> memory image, to make that data trusted. But we can discuss that
> separately.
>
> > - Both SVSMs end up located in a memory slot outside of memory that is
> >   reported to the guest. Coconut-svsm gets the location and size from
> >   fwcfg, which is customizable via the Qemu command line. Linux-svsm gets
> >   the location and size from the build process and validates that location
> >   and size.
>
> Correct, COCONUT also has a fall-back where it just uses the last 16MB
> of guest RAM if the fw_cfg file is not there. That needs OVMF support,
> though.
>
> >   - Pagetables:
> >     Page table support can be tricky with the x86_64 crate. But in general
> >     I believe it could still be used. Coconut-svsm uses a dynamic offset-
> >     based approach for pagetables based on the final physical address
> >     location. This offset could be utilized in the x86_64 crate
> >     implementation. When CPL3 support comes around, that would require
> >     further investigation.
>
> Yeah, COCONUT does not only use an offset mapping, it also has specific
> mappings for the per-cpu areas. Those are mapped at a fixed location,
> same with stacks, so the needs already go beyond an offset mapping.
>
> > - Coconut-svsm copies the original Secrets Page and the "frees" the memory
> >   for it. I couldn't tell if the memory is zeroed out or not, but
> >   something that should be looked at to ensure the VMPCK0 key is not
> >   leaked.
>
> Thanks, that is a real issue. I just wrote a fix for that.
>
> > Some questions for coconut-svsm:
> >   - Are there any concerns with using existing code/projects as submodules
> >     within coconut-svsm (e.g. OpenSSL or a software TPM implementation)?
> >     One of our design goals for linux-svsm was desirability to easily
> >     allow downstream users or products to, e.g., use their own crypto
> >     (e.g. company preferred)
>
> No concerns from my side to run any code you want in a CPL-3 module.
> This includes code which uses external libraries such as openssl or
> libtpm. The modules will be in an archive file packaged with the SVSM
> binary, so that everything that runs is measured at launch time.
>
> >   - 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.
>
> >   - 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.

> Great move, much appreciated, thanks a lot for that! Let's work together
> to make that happen.
>
> Regards,
>
> --
> Jörg Rödel
> jroedel@suse.de
>
> SUSE Software Solutions Germany GmbH
> Frankenstraße 146
> 90461 Nürnberg
> Germany
>
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>


-- 
-Dionna Glaze, PhD (she/her)