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

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

[Jörg Rödel]

Hi,

We are happy to announce that last week our secure VM service module
(SVSM) went public on GitHub for everyone to try it out and participate
in its further development. It is dual-licensed under the MIT and
APACHE-2.0 licenses.

The project is written in Rust and can be cloned from:

	https://github.com/coconut-svsm/svsm

There are also repositories in the github project with the Linux host and
guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
Linux guest.

The SVSM repository contains an installation guide in the INSTALL.md
file and contributor hints in CONTRIBUTING.md.

A blog entry with more details is here:

	https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/

We also thank AMD for implementing and providing the necessary changes
to Linux and EDK2 to make an SVSM possible.

Have a lot of fun!

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

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

[James Bottomley]

On Tue, 2023-03-21 at 10:29 +0100, Jörg Rödel wrote:
> Hi,
> 
> We are happy to announce that last week our secure VM service module
> (SVSM) went public on GitHub for everyone to try it out and
> participate in its further development. It is dual-licensed under the
> MIT and APACHE-2.0 licenses.
> 
> The project is written in Rust and can be cloned from:
> 
>         https://github.com/coconut-svsm/svsm
> 
> There are also repositories in the github project with the Linux host
> and guest, EDK2 and QEMU changes needed to run the SVSM and boot up a
> full Linux guest.
> 
> The SVSM repository contains an installation guide in the INSTALL.md
> file and contributor hints in CONTRIBUTING.md.
> 
> A blog entry with more details is here:
> 
>         
> https://www.suse.com/c/suse-open-sources-secure-vm-service-module-
> for-confidential-computing/
> 
> We also thank AMD for implementing and providing the necessary
> changes to Linux and EDK2 to make an SVSM possible.

Since this a fork of the AMD svsm code
(https://github.com/AMDESE/linux-svsm/), is it intended to be a
permanent fork, or are you going to be submitting your additions back
upstream like we're trying to do for our initial vTPM prototype?  From
the community point of view, having two different SVSM code bases and
having to choose which one to develop against is going to be very
confusing ...

James

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

[Jörg Rödel]

Hi James,

On Tue, Mar 21, 2023 at 07:09:40AM -0400, James Bottomley wrote:
> Since this a fork of the AMD svsm code
> (https://github.com/AMDESE/linux-svsm/), is it intended to be a
> permanent fork, or are you going to be submitting your additions back
> upstream like we're trying to do for our initial vTPM prototype?  From
> the community point of view, having two different SVSM code bases and
> having to choose which one to develop against is going to be very
> confusing ...

The COCONUT-SVSM was and is a separate project and not a fork of AMDs
linux-svsm. Some code was ported from our code-base to linux-svsm in the
past, namely the SpinLock implementation and the memory allocators.

What the project also shares with linux-svsm is the support code in the
Linux kernel (host and guest) and the EDK2 changes needed to launch an
SVSM.

But besides that the two code-bases are different, using a different
build approach and different launch protocol. The goals we have with our
SVSM are hard to achieve with the linux-svsm code-base, so a merge does
not make sense at this point.

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

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

[James Bottomley]

On Tue, 2023-03-21 at 13:43 +0100, Jörg Rödel wrote:
> Hi James,
> 
> On Tue, Mar 21, 2023 at 07:09:40AM -0400, James Bottomley wrote:
> > Since this a fork of the AMD svsm code
> > (https://github.com/AMDESE/linux-svsm/), is it intended to be a
> > permanent fork, or are you going to be submitting your additions
> > back upstream like we're trying to do for our initial vTPM
> > prototype? From the community point of view, having two different
> > SVSM code bases and having to choose which one to develop against
> > is going to be very confusing ...
> 
> The COCONUT-SVSM was and is a separate project and not a fork of AMDs
> linux-svsm. Some code was ported from our code-base to linux-svsm in
> the past, namely the SpinLock implementation and the memory
> allocators.

Well at the time you submitted the pull request, Coconut wasn't public,
so I don't think it looked like a port from a separate code base when
it happened.  But anyway, I'm not so interested in who is based on
whom, I'm more interested in how we avoid dividing our efforts on
confidential computing going forwards.

> What the project also shares with linux-svsm is the support code in
> the Linux kernel (host and guest) and the EDK2 changes needed to
> launch an SVSM.
> 
> But besides that the two code-bases are different, using a different
> build approach and different launch protocol. The goals we have with
> our SVSM are hard to achieve with the linux-svsm code-base, so a
> merge does not make sense at this point.

Could you describe these incompatible goals and explain why you think
they are incompatible (as in why you and AMD don't think you can agree
on it)?  That would help the rest of us understand where the two SVSM
implementations fit in our ongoing plans.

Regards,

James

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

[Jörg Rödel]

On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote:
> Could you describe these incompatible goals and explain why you think
> they are incompatible (as in why you and AMD don't think you can agree
> on it)?  That would help the rest of us understand where the two SVSM
> implementations fit in our ongoing plans.

The goal of COCONUT is to have an SVSM which has isolation capabilities
within itself. It already has percpu page-tables and in the end it will
be able to run services (like the TPM) as separate processes in ring 3
using cooperative multitasking.

With the current linux-svsm code-base this is difficult to achieve due
to its reliance on the x86-64 crate. For supporting a user-space like
execution mode the crate has too many limitations, mainly in its
page-table and IDT implementations.

The IDT code from that crate, which is also used in linux-svsm, relies
on compiler-generated entry-code. This is not enough to support a
ring-3 execution mode with syscalls and several (possibly nested) IST
vectors. The next problem with the IDT code is that it doesn't allow
modification of return register state.  This makes it impossible to
implement exception fixups to guard RMPADJUST instructions and VMPL1
memory accesses in general.

When we looked at the crate, the page-table implementation supported
basically a direct and an offset mapping, which will get us into
problems when support for non-contiguous mappings or sharing parts of a
page-table with another page-table is needed. So in the very beginning
of the project I decided to go with my own page-table implementation.

Of course we could start changing linux-svsm to support the same goals,
but I think the end result will not be very different from what COCONUT
looks now.

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

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

[Dr. David Alan Gilbert]

* Jörg Rödel (jroedel@suse.de) wrote:
> On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote:
> > Could you describe these incompatible goals and explain why you think
> > they are incompatible (as in why you and AMD don't think you can agree
> > on it)?  That would help the rest of us understand where the two SVSM
> > implementations fit in our ongoing plans.
> 
> The goal of COCONUT is to have an SVSM which has isolation capabilities
> within itself. It already has percpu page-tables and in the end it will
> be able to run services (like the TPM) as separate processes in ring 3
> using cooperative multitasking.
> 
> With the current linux-svsm code-base this is difficult to achieve due
> to its reliance on the x86-64 crate. For supporting a user-space like
> execution mode the crate has too many limitations, mainly in its
> page-table and IDT implementations.
> 
> The IDT code from that crate, which is also used in linux-svsm, relies
> on compiler-generated entry-code. This is not enough to support a
> ring-3 execution mode with syscalls and several (possibly nested) IST
> vectors. The next problem with the IDT code is that it doesn't allow
> modification of return register state.  This makes it impossible to
> implement exception fixups to guard RMPADJUST instructions and VMPL1
> memory accesses in general.

I'm curious why you're doing isolation using ring-3 stuff rather than
another VMPL level?

Dave

> When we looked at the crate, the page-table implementation supported
> basically a direct and an offset mapping, which will get us into
> problems when support for non-contiguous mappings or sharing parts of a
> page-table with another page-table is needed. So in the very beginning
> of the project I decided to go with my own page-table implementation.
> 
> Of course we could start changing linux-svsm to support the same goals,
> but I think the end result will not be very different from what COCONUT
> looks now.
> 
> 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Jörg Rödel]

On Tue, Mar 21, 2023 at 05:48:38PM +0000, Dr. David Alan Gilbert wrote:
> I'm curious why you're doing isolation using ring-3 stuff rather than
> another VMPL level?

Two reasons:

1) CPL switch is much cheaper than VMPL switch

2) CPLs allow to isolate different services within the same VMPL. Having
   services run at, say, VMPL1 on CPL-0 will allow all services on VMPL1
   to access each others memory.

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

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

[James Bottomley]

On Tue, 2023-03-21 at 16:14 +0100, Jörg Rödel wrote:
> On Tue, Mar 21, 2023 at 09:43:48AM -0400, James Bottomley wrote:
> > Could you describe these incompatible goals and explain why you
> > think they are incompatible (as in why you and AMD don't think you
> > can agree on it)?  That would help the rest of us understand where
> > the two SVSM implementations fit in our ongoing plans.
> 
> The goal of COCONUT is to have an SVSM which has isolation
> capabilities within itself. It already has percpu page-tables and in
> the end it will be able to run services (like the TPM) as separate
> processes in ring 3 using cooperative multitasking.
> 
> With the current linux-svsm code-base this is difficult to achieve
> due to its reliance on the x86-64 crate. For supporting a user-space
> like execution mode the crate has too many limitations, mainly in its
> page-table and IDT implementations.
> 
> The IDT code from that crate, which is also used in linux-svsm,
> relies on compiler-generated entry-code. This is not enough to
> support a ring-3 execution mode with syscalls and several (possibly
> nested) IST vectors. The next problem with the IDT code is that it
> doesn't allow modification of return register state.  This makes it
> impossible to implement exception fixups to guard RMPADJUST
> instructions and VMPL1 memory accesses in general.
> 
> When we looked at the crate, the page-table implementation supported
> basically a direct and an offset mapping, which will get us into
> problems when support for non-contiguous mappings or sharing parts of
> a page-table with another page-table is needed. So in the very
> beginning of the project I decided to go with my own page-table
> implementation.

OK, so this doesn't sound like a problem with the AMD svsm, it sounds
like a (solvable) issue with a particular crate in embedded rust.  I
have to say that embedded rust is so new, it's really hard to tell if
this is just because it was developed by someone who didn't think of
all the OS implications or because it's a fundamental issue within the
rust ecosystem.  Have you tried improving this crate? ... and also it's
a nuisance we came to with our insistence on using rust; it certainly
wouldn't have been an issue in C.  I suspect improving the crate would
help everyone (although I note the linux kernel isn't yet using this
crate either).

> Of course we could start changing linux-svsm to support the same
> goals, but I think the end result will not be very different from
> what COCONUT looks now.

That's entirely possible, so what are the chances of combining the
projects now so we don't get a split in community effort?

James

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

[Marc Orr]

On Tue, Mar 21, 2023 at 1:05 PM James Bottomley <jejb@linux.ibm.com> wrote:
>
> > Of course we could start changing linux-svsm to support the same
> > goals, but I think the end result will not be very different from
> > what COCONUT looks now.
>
> That's entirely possible, so what are the chances of combining the
> projects now so we don't get a split in community effort?

Very cool to see this announcement and read the discussion!

One SVSM will be better for Google too. Specifically:
- One hypervisor/SVSM startup sequence is easier for us to get working
- One SVSM is easier to test/qualify/deploy
- Generally speaking, things will be easier for us if all SNP VMs
start running off of the same "first mutable code". I.e., the same
SVSM, UEFI, etc.

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

[Daniel P. Berrangé]

On Tue, Mar 21, 2023 at 06:29:29PM -0700, Marc Orr wrote:
> On Tue, Mar 21, 2023 at 1:05 PM James Bottomley <jejb@linux.ibm.com> wrote:
> >
> > > Of course we could start changing linux-svsm to support the same
> > > goals, but I think the end result will not be very different from
> > > what COCONUT looks now.
> >
> > That's entirely possible, so what are the chances of combining the
> > projects now so we don't get a split in community effort?
> 
> Very cool to see this announcement and read the discussion!
> 
> One SVSM will be better for Google too. Specifically:
> - One hypervisor/SVSM startup sequence is easier for us to get working
> - One SVSM is easier to test/qualify/deploy
> - Generally speaking, things will be easier for us if all SNP VMs
> start running off of the same "first mutable code". I.e., the same
> SVSM, UEFI, etc.

I agree with this from the Red Hat side. We would prefer there to
be a standard / common SVSM used by all [OSS] hypervisors/clouds,
to reduce permutations that guest OS vendors/tenants have to
develop/test/deploy against.

It looks like even developing one high quality feature rich SVSM
is a non-trivial undertaking, so I agree with James that it is
undesirable to divide community resources across many competing
impls, without a compelling justification.

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

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

[Jörg Rödel]

On Tue, Mar 21, 2023 at 04:05:35PM -0400, James Bottomley wrote:
> OK, so this doesn't sound like a problem with the AMD svsm, it sounds
> like a (solvable) issue with a particular crate in embedded rust.  I
> have to say that embedded rust is so new, it's really hard to tell if
> this is just because it was developed by someone who didn't think of
> all the OS implications or because it's a fundamental issue within the
> rust ecosystem.  Have you tried improving this crate? ... and also it's
> a nuisance we came to with our insistence on using rust; it certainly
> wouldn't have been an issue in C.  I suspect improving the crate would
> help everyone (although I note the linux kernel isn't yet using this
> crate either).

We did not consider to work on the x86-64 crate for now, that would open
a new can of worms and would have delayed the project even further. I
agree that the crate would benefit from that, but targeting questions
like how to introduce new functionality while keeping it compatible to
other users is a project on its own.

COCONUT is now in a state where it has its own page-table and IDT/entry
code implementations which fit its needs and can be quickly adapted as
we move forward. When the dust settles we can re-visit that question and
start contributing back to this crate and possibly adopt it.

There is actually one thing from the crate I would like to have in
COCONUT too, which is the abstraction for VirtAddr and PhysAddr. COCONUT
just defines those as usize, which is rather limited and leads to ugly
code here and there.

> That's entirely possible, so what are the chances of combining the
> projects now so we don't get a split in community effort?

That is not on us to decide. I agree that a single effort is much
better, but at the same time I don't think that porting upstream code
between both implementations is worthwile (things are different with the
work that is currently happening on-top of linux-svsm).

From a functionality pov both projects are mostly on par in their
upstream branches. COCONUT is lacking one piece or another, like it does
not work around the VMSA@2M-aligned erratum yet. On the other hand
COCONUT has a bigger code-base, implementing exception fixups and
bracktraces already.  Soon COCONUT will gain an ELF parser (and building
on that ASLR) to load the SVSM kernel as an ELF file from the stage2
loader. The ELF parser is needed anyway for ring-3 support, other
changes are also under development.

There is of course work building on linux-svsm out there, too. It would
be interesting to get an overview of that. We are already looking into
porting over the attestation code IBM wrote for linux-svsm (although we
would prefer IBM submitting it :) ). The vTPM code out there can not be
ported over as-is, as COCONUT will not link a whole TPM library in its
code-base. But maybe it can be the base for a separate vTPM binary run
by COCONUT.

In general, since both projects are written in Rust and the APIs are
small, it is not a big effort to port over changes for linux-svsm to
COCONUT.

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

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

[Daniel P. Berrangé]

On Wed, Mar 22, 2023 at 10:15:33AM +0100, Jörg Rödel wrote:
> There is of course work building on linux-svsm out there, too. It would
> be interesting to get an overview of that. We are already looking into
> porting over the attestation code IBM wrote for linux-svsm (although we
> would prefer IBM submitting it :) ). The vTPM code out there can not be
> ported over as-is, as COCONUT will not link a whole TPM library in its
> code-base. But maybe it can be the base for a separate vTPM binary run
> by COCONUT.

For whichever SVSM impl becomes the dominant, the vTPM support with
persistence, is something I see as a critical component. It lets the
guest OS boot process at least be largely decoupled from the CVM
attestation process, and instead rely on the pre-existing support for
TPMs, SecureBoot & secret sealing which is common to bare metal and
non-confidential VM deployments alike. 

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

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

[Dionna Amalie Glaze]

On Wed, Mar 22, 2023 at 11:08 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Mar 22, 2023 at 10:15:33AM +0100, Jörg Rödel wrote:
> > There is of course work building on linux-svsm out there, too. It would
> > be interesting to get an overview of that. We are already looking into
> > porting over the attestation code IBM wrote for linux-svsm (although we
> > would prefer IBM submitting it :) ). The vTPM code out there can not be
> > ported over as-is, as COCONUT will not link a whole TPM library in its
> > code-base. But maybe it can be the base for a separate vTPM binary run
> > by COCONUT.
>
> For whichever SVSM impl becomes the dominant, the vTPM support with
> persistence, is something I see as a critical component. It lets the
> guest OS boot process at least be largely decoupled from the CVM
> attestation process, and instead rely on the pre-existing support for
> TPMs, SecureBoot & secret sealing which is common to bare metal and
> non-confidential VM deployments alike.
>

NVDATA in a confidential setting in my mind needs a whole an attested
sealing key escrow service to really remove the host from the trust
boundary.
Ideally the service never goes down and can have an unbroken chain of
custody back to the original ingestion into the service.
If the service ever has all machines go down, it would have to have
another trusted service of rollback-safe files. That depends on
trusted time.

The service nodes plays hot potato with key replication and has logged
and attested cluster management operations:
*  sealing secrets forward to a new version that was signed by a
pre-registered trusted operator.
*  adding more machines to a cluster that has access to the secrets by
a trusted operator.
*  the sealing enclaves themselves need a secure source of time to
know when the enclave came up and whether it got its secrets from a
rollback-safe sealed-to-code file or will depend on gossip.

Trusted persistence really means there's some trusted workload that
never goes down that is able to take a sealing key bound to an
expected workload measurement and return a secret that will only be
unsealed when the vTPM gets to the bound measurement.

It's a fun problem, one I've been wanting to work on, but yeah there's
a bunch of other more pressing work to do first.

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


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

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

[Dr. David Alan Gilbert]

* Jörg Rödel (jroedel@suse.de) wrote:
> Hi,
> 
> We are happy to announce that last week our secure VM service module
> (SVSM) went public on GitHub for everyone to try it out and participate
> in its further development. It is dual-licensed under the MIT and
> APACHE-2.0 licenses.
> 
> The project is written in Rust and can be cloned from:
> 
> 	https://github.com/coconut-svsm/svsm
> 
> There are also repositories in the github project with the Linux host and
> guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
> Linux guest.
> 
> The SVSM repository contains an installation guide in the INSTALL.md
> file and contributor hints in CONTRIBUTING.md.
> 
> A blog entry with more details is here:
> 
> 	https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/
> 
> We also thank AMD for implementing and providing the necessary changes
> to Linux and EDK2 to make an SVSM possible.

Interesting; it would have been nice to have known about this a little
earlier, some people have been working on stuff built on top of the AMD
one for a while.

You mention two things that I wonder how they interact:

  a) TPMs in the future at a higher ring
  b) Making (almost) unmodified guests

What interface do you expect the guest to see from the TPM - would it
look like an existing TPM hardware interface or would you need some
changes?

Dave

> Have a lot of fun!
> 
> -- 
> 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Jörg Rödel]

Hi Dave,

On Tue, Mar 21, 2023 at 03:06:19PM +0000, Dr. David Alan Gilbert wrote:
> Interesting; it would have been nice to have known about this a little
> earlier, some people have been working on stuff built on top of the AMD
> one for a while.

Sorry for that, we wanted to have it in a state where it could at least
boot an SMP Linux guest. It took us some more time to get the
foundations right and get to that point.

> You mention two things that I wonder how they interact:
> 
>   a) TPMs in the future at a higher ring
>   b) Making (almost) unmodified guests
> 
> What interface do you expect the guest to see from the TPM - would it
> look like an existing TPM hardware interface or would you need some
> changes?

For a) without b) the guest interface will be the SVSM TPM protocol. The
ring-0 code will forward any request to the TPM process and return to
the guest when it is done.

For b), or the paravisor mode, this is the vision, which is probably
more than a year out. The idea behind that is to be able to emulate what
Hyper-V is doing to boot Windows guests under SEV-SNP on an open source
SW stack.

How the TPM interface will look like for that paravisor mode is not
clear yet. In theory we can emulate a real TPM interface to make this
work, but that is not sure yet.

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

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

[Dr. David Alan Gilbert]

* Jörg Rödel (jroedel@suse.de) wrote:
> Hi Dave,
> 
> On Tue, Mar 21, 2023 at 03:06:19PM +0000, Dr. David Alan Gilbert wrote:
> > Interesting; it would have been nice to have known about this a little
> > earlier, some people have been working on stuff built on top of the AMD
> > one for a while.
> 
> Sorry for that, we wanted to have it in a state where it could at least
> boot an SMP Linux guest. It took us some more time to get the
> foundations right and get to that point.
> 
> > You mention two things that I wonder how they interact:
> > 
> >   a) TPMs in the future at a higher ring
> >   b) Making (almost) unmodified guests
> > 
> > What interface do you expect the guest to see from the TPM - would it
> > look like an existing TPM hardware interface or would you need some
> > changes?
> 
> For a) without b) the guest interface will be the SVSM TPM protocol. The
> ring-0 code will forward any request to the TPM process and return to
> the guest when it is done.
> 
> For b), or the paravisor mode, this is the vision, which is probably
> more than a year out. The idea behind that is to be able to emulate what
> Hyper-V is doing to boot Windows guests under SEV-SNP on an open source
> SW stack.
> 
> How the TPM interface will look like for that paravisor mode is not
> clear yet. In theory we can emulate a real TPM interface to make this
> work, but that is not sure yet.

OK, I'm just trying to avoid having guests that have a zillion different
TPM setups for different SVSM and clouds.

Timing is a little tricky here; in many ways the thing that sounds
nicest to me about Coconut is the mostly-unmodified guest (b) - but if
that's a while out then hmm.

Dave

> 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Jörg Rödel]

On Tue, Mar 21, 2023 at 04:56:20PM +0000, Dr. David Alan Gilbert wrote:
> OK, I'm just trying to avoid having guests that have a zillion different
> TPM setups for different SVSM and clouds.

My guess it that it will either be the SVSM TPM protocol or an emulation
of an existing TPM interface.

> Timing is a little tricky here; in many ways the thing that sounds
> nicest to me about Coconut is the mostly-unmodified guest (b) - but if
> that's a while out then hmm.

Yeah, would be nice. But we are still in the early stages of SVSM
development, so the priority now is to get services up and running.

But the project is open source and anyone can start looking into the
unmodified guest handling and send PRs. Making this happen is certainly
a multi-step process, as it requires several things to be implemented.
Just out of my head an incomplete list what is required:

	1) ReflectVC handling with instruction decoder and guest TLB
	   flush awareness
	2) vTOM handling
	3) Interrupt proxying using alternate injection (that can make
	   sense even earlier and without the other features imho)

So its quite some work, but if someone wants to look into that now I am
all for it.

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

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

[Dr. David Alan Gilbert]

* Jörg Rödel (jroedel@suse.de) wrote:
> On Tue, Mar 21, 2023 at 04:56:20PM +0000, Dr. David Alan Gilbert wrote:
> > OK, I'm just trying to avoid having guests that have a zillion different
> > TPM setups for different SVSM and clouds.
> 
> My guess it that it will either be the SVSM TPM protocol or an emulation
> of an existing TPM interface.

OK; the other thing that needs to get nailed down for the vTPM's is the
relationship between the vTPM attestation and the SEV attestation.
i.e. how to prove that the vTPM you're dealing with is from an SNP host.
(Azure have a hack of putting an SNP attestation report into the vTPM
NVRAM; see
https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
)

> > Timing is a little tricky here; in many ways the thing that sounds
> > nicest to me about Coconut is the mostly-unmodified guest (b) - but if
> > that's a while out then hmm.
> 
> Yeah, would be nice. But we are still in the early stages of SVSM
> development, so the priority now is to get services up and running.
> 
> But the project is open source and anyone can start looking into the
> unmodified guest handling and send PRs. Making this happen is certainly
> a multi-step process, as it requires several things to be implemented.
> Just out of my head an incomplete list what is required:
> 
> 	1) ReflectVC handling with instruction decoder and guest TLB
> 	   flush awareness
> 	2) vTOM handling
> 	3) Interrupt proxying using alternate injection (that can make
> 	   sense even earlier and without the other features imho)

So all the easy stuff then :-)

> So its quite some work, but if someone wants to look into that now I am
> all for it.

Dave
> 
> 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Jörg Rödel]

On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote:
> OK; the other thing that needs to get nailed down for the vTPM's is the
> relationship between the vTPM attestation and the SEV attestation.
> i.e. how to prove that the vTPM you're dealing with is from an SNP host.
> (Azure have a hack of putting an SNP attestation report into the vTPM
> NVRAM; see
> https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
> )

When using the SVSM TPM protocol it should be proven already that the
vTPM is part of the SNP trusted base, no? The TPM communication is
implicitly encrypted by the VMs memory key and the SEV attestation
report proves that the correct vTPM is executing.

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

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

[Alexander Graf]

Hi Jörg,

On 22.03.23 10:19, Jörg Rödel wrote:

> On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote:
>> OK; the other thing that needs to get nailed down for the vTPM's is the
>> relationship between the vTPM attestation and the SEV attestation.
>> i.e. how to prove that the vTPM you're dealing with is from an SNP host.
>> (Azure have a hack of putting an SNP attestation report into the vTPM
>> NVRAM; see
>> https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
>> )
> When using the SVSM TPM protocol it should be proven already that the
> vTPM is part of the SNP trusted base, no? The TPM communication is
> implicitly encrypted by the VMs memory key and the SEV attestation
> report proves that the correct vTPM is executing.


What you want to achieve eventually is to take a report from the vTPM 
and submit only that to an external authorization entity that looks at 
it and says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM 
implementation, I also trust your PCR values" and based on that provides 
access to whatever resource you want to access.

To do that, you need to link SEV-SNP and TPM measurements/reports 
together. And the easiest way to do that is by providing the SEV-SNP 
report as part of the TPM: You can then use the hash of the SEV-SNP 
report as signing key for example.

I think the key here is that you need to propagate that link to an 
external party, not (only) to the VM.


Alex





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

[Dr. David Alan Gilbert]

* Alexander Graf (graf@amazon.com) wrote:
> Hi Jörg,
> 
> On 22.03.23 10:19, Jörg Rödel wrote:
> 
> > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote:
> > > OK; the other thing that needs to get nailed down for the vTPM's is the
> > > relationship between the vTPM attestation and the SEV attestation.
> > > i.e. how to prove that the vTPM you're dealing with is from an SNP host.
> > > (Azure have a hack of putting an SNP attestation report into the vTPM
> > > NVRAM; see
> > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
> > > )
> > When using the SVSM TPM protocol it should be proven already that the
> > vTPM is part of the SNP trusted base, no? The TPM communication is
> > implicitly encrypted by the VMs memory key and the SEV attestation
> > report proves that the correct vTPM is executing.
> 
> 
> What you want to achieve eventually is to take a report from the vTPM and
> submit only that to an external authorization entity that looks at it and
> says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM
> implementation, I also trust your PCR values" and based on that provides
> access to whatever resource you want to access.
> 
> To do that, you need to link SEV-SNP and TPM measurements/reports together.
> And the easiest way to do that is by providing the SEV-SNP report as part of
> the TPM: You can then use the hash of the SEV-SNP report as signing key for
> example.

Yeh; I think the SVSM TPM protocol has some proof of that as well; the
SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains
'TPMT_PUBLIC structure of the endorsement key'.
So I *think* that's saying that the SEV attestation report contains
something from the EK of the vTPM.

> I think the key here is that you need to propagate that link to an external
> party, not (only) to the VM.

Yeh.

Dave
> 
> 
> Alex
> 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Dionna Amalie Glaze]

On Wed, Mar 22, 2023 at 3:34 AM Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> * Alexander Graf (graf@amazon.com) wrote:
> > Hi Jörg,
> >
> > On 22.03.23 10:19, Jörg Rödel wrote:
> >
> > > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote:
> > > > OK; the other thing that needs to get nailed down for the vTPM's is the
> > > > relationship between the vTPM attestation and the SEV attestation.
> > > > i.e. how to prove that the vTPM you're dealing with is from an SNP host.
> > > > (Azure have a hack of putting an SNP attestation report into the vTPM
> > > > NVRAM; see
> > > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
> > > > )
> > > When using the SVSM TPM protocol it should be proven already that the
> > > vTPM is part of the SNP trusted base, no? The TPM communication is
> > > implicitly encrypted by the VMs memory key and the SEV attestation
> > > report proves that the correct vTPM is executing.
> >
> >
> > What you want to achieve eventually is to take a report from the vTPM and
> > submit only that to an external authorization entity that looks at it and
> > says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM
> > implementation, I also trust your PCR values" and based on that provides
> > access to whatever resource you want to access.
> >
> > To do that, you need to link SEV-SNP and TPM measurements/reports together.
> > And the easiest way to do that is by providing the SEV-SNP report as part of
> > the TPM: You can then use the hash of the SEV-SNP report as signing key for
> > example.
>
> Yeh; I think the SVSM TPM protocol has some proof of that as well; the
> SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains
> 'TPMT_PUBLIC structure of the endorsement key'.
> So I *think* that's saying that the SEV attestation report contains
> something from the EK of the vTPM.
>
> > I think the key here is that you need to propagate that link to an external
> > party, not (only) to the VM.
>
> Yeh.
>

Excuse my perhaps naivete, but would it not be in the TCG's wheelhouse
to specify how a TPM's firmware (SVSM) / bootloader (SEV-SNP) should
be attested? The EK as well?

I think this might need to jump back to the vTPM protocol thread since
this is about COCONUT, but I'm worried we're talking about
AMD-specific long-term formats when perhaps the trusted computing
group should be widening its scope to how a TPM should be virtualized.
I appreciate that we're attempting to solve the problem in the short
term, and certainly the SVSM will need attestation capabilities, but
the linking to the TPM is dicey without that conversation with TCG,
IMHO.

> Dave
> >
> >
> > Alex
> >
> >
> >
> >
> >
> > Amazon Development Center Germany GmbH
> > Krausenstr. 38
> > 10117 Berlin
> > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> > Sitz: Berlin
> > Ust-ID: DE 289 237 879
> >
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>


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

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

[Dr. David Alan Gilbert]

* Dionna Amalie Glaze (dionnaglaze@google.com) wrote:
> On Wed, Mar 22, 2023 at 3:34 AM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Alexander Graf (graf@amazon.com) wrote:
> > > Hi Jörg,
> > >
> > > On 22.03.23 10:19, Jörg Rödel wrote:
> > >
> > > > On Tue, Mar 21, 2023 at 07:53:58PM +0000, Dr. David Alan Gilbert wrote:
> > > > > OK; the other thing that needs to get nailed down for the vTPM's is the
> > > > > relationship between the vTPM attestation and the SEV attestation.
> > > > > i.e. how to prove that the vTPM you're dealing with is from an SNP host.
> > > > > (Azure have a hack of putting an SNP attestation report into the vTPM
> > > > > NVRAM; see
> > > > > https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md
> > > > > )
> > > > When using the SVSM TPM protocol it should be proven already that the
> > > > vTPM is part of the SNP trusted base, no? The TPM communication is
> > > > implicitly encrypted by the VMs memory key and the SEV attestation
> > > > report proves that the correct vTPM is executing.
> > >
> > >
> > > What you want to achieve eventually is to take a report from the vTPM and
> > > submit only that to an external authorization entity that looks at it and
> > > says "Yup, you ran in SEV-SNP, I trust your TCB, I trust your TPM
> > > implementation, I also trust your PCR values" and based on that provides
> > > access to whatever resource you want to access.
> > >
> > > To do that, you need to link SEV-SNP and TPM measurements/reports together.
> > > And the easiest way to do that is by providing the SEV-SNP report as part of
> > > the TPM: You can then use the hash of the SEV-SNP report as signing key for
> > > example.
> >
> > Yeh; I think the SVSM TPM protocol has some proof of that as well; the
> > SVSM spec lists 'SVSM_ATTEST_SINGLE_SERVICE Manifest Data' that contains
> > 'TPMT_PUBLIC structure of the endorsement key'.
> > So I *think* that's saying that the SEV attestation report contains
> > something from the EK of the vTPM.
> >
> > > I think the key here is that you need to propagate that link to an external
> > > party, not (only) to the VM.
> >
> > Yeh.
> >
> 
> Excuse my perhaps naivete, but would it not be in the TCG's wheelhouse
> to specify how a TPM's firmware (SVSM) / bootloader (SEV-SNP) should
> be attested? The EK as well?
> 
> I think this might need to jump back to the vTPM protocol thread since
> this is about COCONUT, but I'm worried we're talking about
> AMD-specific long-term formats when perhaps the trusted computing
> group should be widening its scope to how a TPM should be virtualized.
> I appreciate that we're attempting to solve the problem in the short
> term, and certainly the SVSM will need attestation capabilities, but
> the linking to the TPM is dicey without that conversation with TCG,
> IMHO.

Some standardisation of the link between the vTPM and the underlying
CoCo hardware would be great; there's at least 2 or 3 CoCo linked vTPMs
already and I don't think they're sharing any idea of that.

Whether it's TCG I'm not sure; It doesn't seem to me to make sense for
them to specify the flow to bring the vTPM up or the details of the
underlying CoCo's attestation; but standardising how the two processes
are tied together might be possible.

Dave

> > Dave
> > >
> > >
> > > Alex
> > >
> > >
> > >
> > >
> > >
> > > Amazon Development Center Germany GmbH
> > > Krausenstr. 38
> > > 10117 Berlin
> > > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> > > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> > > Sitz: Berlin
> > > Ust-ID: DE 289 237 879
> > >
> > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
> >
> 
> 
> -- 
> -Dionna Glaze, PhD (she/her)
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[James Bottomley]

On Wed, 2023-03-22 at 17:47 +0000, Dr. David Alan Gilbert wrote:
[...]
> > I think this might need to jump back to the vTPM protocol thread
> > since this is about COCONUT, but I'm worried we're talking about
> > AMD-specific long-term formats when perhaps the trusted computing
> > group should be widening its scope to how a TPM should be
> > virtualized. I appreciate that we're attempting to solve the
> > problem in the short term, and certainly the SVSM will need
> > attestation capabilities, but the linking to the TPM is dicey
> > without that conversation with TCG, IMHO.
> 
> Some standardisation of the link between the vTPM and the underlying
> CoCo hardware would be great; there's at least 2 or 3 CoCo linked
> vTPMs already and I don't think they're sharing any idea of that.

Well, for SNP, it's easy: the VMPL0 labelled attestation report proves
the SVSM and other components including OVMF and vTPM code
implementation.  We insert a hash of the manufactured EK into the
report and that gives proof from the trusted SVSM of the EK belonging
to the vTPM (essentially binding the vTPM to the VM).  The same thing
would work for other CoCo VM environments.

If we do ephemeral vTPMs, the binding is one time and there's no
persistent state security issue, so the SVSM-vTPM attestation is all
you need to begin trusting the vTPM measurements.

> Whether it's TCG I'm not sure; It doesn't seem to me to make sense
> for them to specify the flow to bring the vTPM up or the details of
> the underlying CoCo's attestation; but standardising how the two
> processes are tied together might be possible.

I think the TCG is probably not going to touch that because how you
attest the code that will run as the SVSM and vTPM is very specific to
each CoCo implementation.  However, they all provide a user data like
field which allows you to add information from the to be verified as
trusted SVSM, so you can use it for the EK, which is pretty identical
to the above proposal.

James

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

[Tom Lendacky]

On 3/21/23 04:29, Jörg Rödel wrote:
> Hi,
> 
> We are happy to announce that last week our secure VM service module
> (SVSM) went public on GitHub for everyone to try it out and participate
> in its further development. It is dual-licensed under the MIT and
> APACHE-2.0 licenses.
> 
> The project is written in Rust and can be cloned from:
> 
> 	https://github.com/coconut-svsm/svsm
> 
> There are also repositories in the github project with the Linux host and
> guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
> Linux guest.
> 
> The SVSM repository contains an installation guide in the INSTALL.md
> file and contributor hints in CONTRIBUTING.md.
> 
> A blog entry with more details is here:
> 
> 	https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/
> 
> We also thank AMD for implementing and providing the necessary changes
> to Linux and EDK2 to make an SVSM possible.

Just wanted to let everyone know that I'm looking into what we can do to 
move towards a single SVSM project so that resources aren't split between 
the two.

I was hoping to have a comparison, questions and observations between the 
two available by now, however, I'm behind on that... but, I am working on it.

Thanks,
Tom

> 
> Have a lot of fun!
> 

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

[Dionna Amalie Glaze]

On Tue, Apr 11, 2023 at 12:57 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> On 3/21/23 04:29, Jörg Rödel wrote:
> > Hi,
> >
> > We are happy to announce that last week our secure VM service module
> > (SVSM) went public on GitHub for everyone to try it out and participate
> > in its further development. It is dual-licensed under the MIT and
> > APACHE-2.0 licenses.
> >
> > The project is written in Rust and can be cloned from:
> >
> >       https://github.com/coconut-svsm/svsm
> >
> > There are also repositories in the github project with the Linux host and
> > guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
> > Linux guest.
> >
> > The SVSM repository contains an installation guide in the INSTALL.md
> > file and contributor hints in CONTRIBUTING.md.
> >
> > A blog entry with more details is here:
> >
> >       https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/
> >
> > We also thank AMD for implementing and providing the necessary changes
> > to Linux and EDK2 to make an SVSM possible.
>
> Just wanted to let everyone know that I'm looking into what we can do to
> move towards a single SVSM project so that resources aren't split between
> the two.
>
> I was hoping to have a comparison, questions and observations between the
> two available by now, however, I'm behind on that... but, I am working on it.
>

This is a happy development. Glad to hear it and thanks for your work,
Tom, Jörg, and all collaborators.

> Thanks,
> Tom
>
> >
> > Have a lot of fun!
> >



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

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

[James Bottomley]

On Tue, 2023-04-11 at 14:57 -0500, Tom Lendacky wrote:
> On 3/21/23 04:29, Jörg Rödel wrote:
> > Hi,
> > 
> > We are happy to announce that last week our secure VM service
> > module (SVSM) went public on GitHub for everyone to try it out and
> > participate in its further development. It is dual-licensed under
> > the MIT and APACHE-2.0 licenses.
> > 
> > The project is written in Rust and can be cloned from:
> > 
> >         https://github.com/coconut-svsm/svsm
> > 
> > There are also repositories in the github project with the Linux
> > host and guest, EDK2 and QEMU changes needed to run the SVSM and
> > boot up a full Linux guest.
> > 
> > The SVSM repository contains an installation guide in the
> > INSTALL.md file and contributor hints in CONTRIBUTING.md.
> > 
> > A blog entry with more details is here:
> > 
> >         https://www.suse.com/c/suse-open-sources-secure-vm-service-
> > module-for-confidential-computing/
> > 
> > We also thank AMD for implementing and providing the necessary
> > changes to Linux and EDK2 to make an SVSM possible.
> 
> Just wanted to let everyone know that I'm looking into what we can do
> to  move towards a single SVSM project so that resources aren't split
> between  the two.
> 
> I was hoping to have a comparison, questions and observations between
> the two available by now, however, I'm behind on that... but, I am
> working on it.

We (IBM) did look at what it might take to add a vTPM to Coconut, but
we ran into the problem that if we do it at CPL3 (which looks
desirable), then we have to wait until pretty much every one of the
twelve(!) tasks in this list is complete:

https://github.com/coconut-svsm/svsm/issues/16

At a conservative estimate, it looks like completion of all twelve
would take a team of people over a year to achieve.  Some of these
tasks, like task switching and a syscall interface, really don't look
like they belong in a simple service module, like we were imagining an
SVSM would operate, is there some rationale behind this (or ideally
some architecture document that gives the justifications)?  I think
what I'm really asking is can we get to CPL3 separation way sooner than
completion of all these tasks?

Regards,

James

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

[Jörg Rödel]

Hi James,

On Thu, Apr 13, 2023 at 12:57:38PM -0400, James Bottomley wrote:
> We (IBM) did look at what it might take to add a vTPM to Coconut, but
> we ran into the problem that if we do it at CPL3 (which looks
> desirable), then we have to wait until pretty much every one of the
> twelve(!) tasks in this list is complete:
> 
> https://github.com/coconut-svsm/svsm/issues/16

Thanks for looking into the code-base. Our approach to getting CPL-3
support is incremental. We can take some shortcuts where possible, as
long as the foundations and the underlying design is right, to get code
running at CPL-3 at some point in 2H/2023.

Looking at the points listed in the issue above, some of them are ready
or almost ready (just not included in the main branch yet):

	* "Archive file in SVSM binary" is implemented
	* "Page allocator enhancements for reference counting pages" is
	  implemented
	* "ELF loader" is implemented, there is a pending PR for it.

The "RAM file system support" is currently being worked on. All of the
listed points probably don't have a 'complete' state, I think we start
with something very simple and improve from that later as needed.

A primary example is the syscall interface, that will certainly evolve
over time as people come along with their own ideas for other modules.

The rough plan moving forward is:

	* Get RAM FS ready
	* Implement a task and address space abstraction which allows
	  to map RAM FS file contents for CPL-3
	* Task switch and sycall entry/exit
	* Example binary to run for initial tests (that will probably be
	  worked on in parallel)

When that is done we can look into how to get a vTPM into a binary and
improve the underlying interface as required.

Of course progress will be faster with more helping hands :-)

There are also a lot of places that don't have a final design yet where
help and discussions are beneficial.

> At a conservative estimate, it looks like completion of all twelve
> would take a team of people over a year to achieve.  Some of these
> tasks, like task switching and a syscall interface, really don't look
> like they belong in a simple service module, like we were imagining an
> SVSM would operate, is there some rationale behind this (or ideally
> some architecture document that gives the justifications)?  I think
> what I'm really asking is can we get to CPL3 separation way sooner than
> completion of all these tasks?

We do not imaging the SVSM to be simple and small, we are imagining it
to be secure and extensible. Of course it will always be smaller than a
full-blown OS, but the vision is that it can do more than running a vTPM
emulation. Also when we start looking into paravisor-like features like
ReflectVC-handling later, the SVSM will certainly not be simple anymore.

When I talked to people about the SVSM I often heard other interesting
ideas what services it can provide. To make this possible and secure the
SVSM needs the ability to run multiple modules at CPL-3. And a task
concept with a simple FS to load those modules from is, in my opinion,
the right approach.

Yes, it takes more time than simpler and less flexible approaches, but
as one of my favourite TV characters put it: "This is the Way" :-)

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

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

[Tom Lendacky]

On 3/21/23 04:29, Jörg Rödel wrote:
> Hi,
> 
> We are happy to announce that last week our secure VM service module
> (SVSM) went public on GitHub for everyone to try it out and participate
> in its further development. It is dual-licensed under the MIT and
> APACHE-2.0 licenses.
> 
> The project is written in Rust and can be cloned from:
> 
> 	https://github.com/coconut-svsm/svsm
> 
> There are also repositories in the github project with the Linux host and
> guest, EDK2 and QEMU changes needed to run the SVSM and boot up a full
> Linux guest.
> 
> The SVSM repository contains an installation guide in the INSTALL.md
> file and contributor hints in CONTRIBUTING.md.
> 
> A blog entry with more details is here:
> 
> 	https://www.suse.com/c/suse-open-sources-secure-vm-service-module-for-confidential-computing/
> 
> We also thank AMD for implementing and providing the necessary changes
> to Linux and EDK2 to make an SVSM possible.
> 
> Have a lot of fun!
> 

I finally found the time to go through coconut-svsm and compare/contrast
it to linux-svsm. Overall, they are very similar once loaded and running.
I also took the time to preview this with a couple of our most prominent
linux-svsm users before I sent it out.

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.

Some of the main differences are (just an accounting, I'm not saying
that one method is any better than the other):

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

   - Coconut-svsm starts in stages. Stage1 starts in 32-bit protected mode
     just below the OVMF firmware (just below 4GB), copies stage2 and the
     SVSM to 64KB where further initialization is performed and ultimately
     with the SVSM being copied to its final location where execution
     continues.

     The current stage1 location could limit the size of the SVSM based on
     the MMIO layout of the guest.

   - Linux-svsm is loaded in its final location and starts in 64-bit long
     mode. This requires extra setup in Qemu for the VMSA, but no
     relocation is needed once it is loaded.

- Coconut-svsm has developed its own IDT and pagetable support instead of
   using the x86_64 crate as linux-svsm does:

   - IDT:
     The main reason for the IDT support was to be able to customize the
     entry code, especially when CPL3 support is added. However, that can
     be done with the x86_64 crate by not using the "abi_x86_interrupt"
     feature.

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

   - The advantage of using the x86_64 crate is getting added testing and
     fixes for issues that might not be immediately evident in a from
     scratch implementation. While not a issue, investigation could be done
     later to see if it is possible to move to those implementations (if
     desired).

- Coconut-svsm uses the ACPI MADT table to detect and boot APs. This works
   well with Qemu or any VMM that builds the MADT table. The linux-svsm
   makes use of the GHCB APIC ID list NAE event.

- Coconut-svsm does not measure the VMPL1 BSP VMSA directly. It uses set
   values that are measured as part of SVSM itself. This does prevent
   coconut-svsm from being able to launch VMPL1 using a different, measured
   BSP initial state. Linux-svsm, after performing some validation, does
   use a separately measured VMPL1 firmware BSP VMSA.

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


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)

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

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


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. I think we do need to sort out the governance question
(maintainers, prioritization, release/schedule model, ...), but I don't
see hard technical blockers. For others in the linux-svsm developer
community, please ask questions or voice any concerns you may have so that
we can see if they can be addressed.

Thanks,
Tom

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

[Jörg Rödel]

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.

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

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

[Dionna Amalie Glaze]

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)

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

[James Bottomley]

On Wed, 2023-05-03 at 08:24 -0700, Dionna Amalie Glaze wrote:
> On Wed, May 3, 2023 at 5:27 AM Jörg Rödel <jroedel@suse.de> wrote:
[...]
> > 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.

From our point of view, having a large set of existing open source
tools which speak the TPM protocol is the big benefit of the vTPM
approach.  Currently the partially closed source Amber attestation
service, which is designed as the recipient of the RTMR protocol, only
understands TDX (and SGX) attestation, so it would be more work than
simply implementing a RTMR approach to make it attach to this tool. 
There would also be the huge problem of how we replicate the quoting
enclave on SEV...

James

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

[Daniel P. Berrangé]

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@suse.de> 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 :|

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

[Claudio Carvalho]

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

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

[Alexander Graf]

On 03.05.23 18:51, Claudio Carvalho wrote:

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


With SVSM, we're reintroducing a new way of doing SMM inside virtual 
machines: A higher privilege mode than can transparently run arbitrary 
code at arbitrary times, invisible to the OS.

That means any bug in that code is fatal. TPM implementations may 
receive untrusted inputs from user space. That means we need to confine 
it as strongly as possible: The syscall interface needs to be as minimal 
and static (no dynamic memory allocations, object livecycles, etc) as 
possible. The less memory we share between the TPM implementation and 
anything outside, the better. Any memory sharing is a potential side 
channel attack target (data) or side channel training target (code).

So to fold this into the paragraph above: Please don't overthink / 
overengineer this. Applications should be as self contained as possible. 
No VDSO, no direct linking. Ideally even fully static at boot memory 
allocation.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

[Jörg Rödel]

Hi Claudio,

On Wed, May 03, 2023 at 12:51:17PM -0400, Claudio Carvalho wrote:
> Thanks. I would be happy to collaborate in that discussion.

Great, I will send out that email early next week to get the discussion
rolling.

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

Right, where to place and how to share the crypto code needs more
discussion, there are multiple possible approaches. I have seen that you
have a talk at KVM Forum, so we can meet there in a larger group and
discuss those and other questions in person.

I think from this thread and other discussions happening it became clear
that there are currently a lot of different opinions on what the SVSM
should do and how it should look like. It would be great if we as a
community can get closer together on those questions (which is certainly
helpful for combining efforts).

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

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

[Daniel P. Berrangé]

On Fri, May 05, 2023 at 05:34:20PM +0200, Jörg Rödel wrote:
> Hi Claudio,
> 
> On Wed, May 03, 2023 at 12:51:17PM -0400, Claudio Carvalho wrote:
> > Thanks. I would be happy to collaborate in that discussion.
> 
> Great, I will send out that email early next week to get the discussion
> rolling.
> 
> > 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.
> 
> Right, where to place and how to share the crypto code needs more
> discussion, there are multiple possible approaches. I have seen that you
> have a talk at KVM Forum, so we can meet there in a larger group and
> discuss those and other questions in person.

Yep, we should probably do a BoF session on the topic of SVSM
for anyone interested who's attending KVM Forum.

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

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

[James Bottomley]

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

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

[Christophe de Dinechin]

On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com> wrote...
> 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'm a but confused regarding the roles that VMPL vs rings is in the security
model here. In particular, I assume that any attack on ring3 would still
have to cross either the VMPL boundary (if coming from the guest) or the TEE
boundary (if coming from the host).

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

And there is definitely a lot of complexity added by supporting ring3. You
are essentially getting the complexity of a "real" operating system. By
contrast, TDX is providing the same kind of isolation with secure enclaves,
but at least the base OS kernel is shared.

The expected benefit is to be able to run more complex code from ring3 with
a better way to handle malfunctions, faults, whatever. At least that's the
way I read it. So it's a way to write software in a more modular way.

IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so presumably,
not accesible from host or guest. If we consider this property as strong,
then do we really care entrusting ring3 with sensitive data?

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

I don't understand what you call "pure code". I presume you mean "code that
does not need to access ring0 data"?

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


--
Cheers,
Christophe de Dinechin (https://c3d.github.io)
Freedom Covenant (https://github.com/c3d/freedom-covenant)
Theory of Incomplete Measurements (https://c3d.github.io/TIM)

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

[James Bottomley]

On Fri, 2023-05-05 at 14:35 +0200, Christophe de Dinechin wrote:
> 
> On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com>
> wrote...
> > On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote:
[...]
> > > 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'm a but confused regarding the roles that VMPL vs rings is in the
> security model here.

Heh, I think that goes for everyone, which is why I'm fishing for
information about the security model.  I don't think its enough to
blindly claim running at cpl3 gives more security, you have to have a
threat model that demonstrates it.

>  In particular, I assume that any attack on ring3 would
> still have to cross either the VMPL boundary (if coming from the
> guest) or the TEE boundary (if coming from the host).

I think the attack theory is more like a privilege escalation: you
induce the SVSM to take a fault through its normal API mechanism by
crafting bad data (this means the runtime attack can only come from the
guest since the host doesn't get access to the SVSM at runtime,
although it could craft bad configuration data for boot time).

Assuming a successful exploit, the attacker now has the ability to run
code in the compromised module.  For a unitary SVSM, that would give
control of the entire SVSM.  For ring 0/3 separation, it should only
give control of the compromised module, which we're assuming is ring 3
code.  However, you're right, in that the attacker now has the ability
to execute VPML0 code, except that some privileged instructions (like
PVALIDATE) can only execute at ring 0, so the attack ability is
slightly more limited.

I've always considered the gold standard exploit of the SVSM to be one
that allows you to fake attestation reports, since then it's game over
as far as remote verification goes, which is why I want the VMPCK0 key
(the communication key VPML0 uses to get VMPL0 specific attestation
reports from the PSP) to be closely guarded at ring 0, making it harder
to compromise remote attestation via exploits.

The flip side is that, assuming the vTPM is the compromised service,
you've already got the ability to fake TPM based runtime attestation,
so its still game over from the remote attestation point of view.  This
leads me to conclude that it really doesn't matter where security
critical protocols run, and the only real advantage of the ring 0/3
separation would come into play if the SVSM had some non-security
critical protocols and it's not clear if it ever will.

> > 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.
> 
> And there is definitely a lot of complexity added by supporting
> ring3. You are essentially getting the complexity of a "real"
> operating system.  By contrast, TDX is providing the same kind of
> isolation with secure enclaves, but at least the base OS kernel is
> shared.
> 
> The expected benefit is to be able to run more complex code from
> ring3 with a better way to handle malfunctions, faults, whatever. At
> least that's the way I read it. So it's a way to write software in a
> more modular way.

Yes, but is that a benefit?  If one of the protocol modules faults, I
think you'd rather have a hard failure of the whole confidential VM
than a restart that gives an attacker more leeway to craft a
compromise.

> IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so
> presumably, not accesible from host or guest. If we consider this
> property as strong, then do we really care entrusting ring3 with
> sensitive data?

Well, as I said above, I think for security critical modules, it
doesn't matter where they run, so perhaps we don't care, but equally
there's not much security benefit to ring 0/3 separation either.

> > 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).
> 
> I don't understand what you call "pure code". I presume you mean
> "code that does not need to access ring0 data"?

I was meaning a VDSO like model, where the openssl crypto code could be
exported from ring-0 as an executable library, but the data would live
with the corresponding consumer, so it could be used by the SVSM body
at ring-0 with any crypto data being held at ring-0 and inaccessible to
ring-3 consumers of the crypto code.

James

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

[Alexander Graf]

On 06.05.23 14:48, James Bottomley wrote:
>
>
> On Fri, 2023-05-05 at 14:35 +0200, Christophe de Dinechin wrote:
>> On 2023-05-04 at 13:04 -04, James Bottomley <jejb@linux.ibm.com>
>> wrote...
>>> On Wed, 2023-05-03 at 14:26 +0200, Jörg Rödel wrote:
> [...]
>>>> 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'm a but confused regarding the roles that VMPL vs rings is in the
>> security model here.
> Heh, I think that goes for everyone, which is why I'm fishing for
> information about the security model.  I don't think its enough to
> blindly claim running at cpl3 gives more security, you have to have a
> threat model that demonstrates it.
>
>>   In particular, I assume that any attack on ring3 would
>> still have to cross either the VMPL boundary (if coming from the
>> guest) or the TEE boundary (if coming from the host).
> I think the attack theory is more like a privilege escalation: you
> induce the SVSM to take a fault through its normal API mechanism by
> crafting bad data (this means the runtime attack can only come from the
> guest since the host doesn't get access to the SVSM at runtime,
> although it could craft bad configuration data for boot time).
>
> Assuming a successful exploit, the attacker now has the ability to run
> code in the compromised module.  For a unitary SVSM, that would give
> control of the entire SVSM.  For ring 0/3 separation, it should only
> give control of the compromised module, which we're assuming is ring 3
> code.  However, you're right, in that the attacker now has the ability
> to execute VPML0 code, except that some privileged instructions (like
> PVALIDATE) can only execute at ring 0, so the attack ability is
> slightly more limited.


I think we're munging 2 things into the same conversation:

* Running code at lower privilege level so code execution attacks can 
not elevate beyond that code's area of responsibility
* Running code with its own address space, so accidental data leaks 
don't leak additionally sensitive information

I personally care more about the latter than the former, mostly also 
because of speculation side channel attacks. I really don't want to be 
in a world where you can train the branch predictor of the vTPM to 
access kernel memory. Code execution gadgets are less prevalent, 
especially if you use rust as programming language.

> I've always considered the gold standard exploit of the SVSM to be one
> that allows you to fake attestation reports, since then it's game over
> as far as remote verification goes, which is why I want the VMPCK0 key
> (the communication key VPML0 uses to get VMPL0 specific attestation
> reports from the PSP) to be closely guarded at ring 0, making it harder
> to compromise remote attestation via exploits.


IMHO that's slightly too focused on the attestation part of the story. 
Imagine an environment where someone managed to gain RCE in a random 
user space application of your VM that has no access to actual secrets / 
PEI / etc. Like a monitoring service running log4j :). That service 
however may have access to /dev/tpm0 (via whatever means) and thus is 
able to craft requests to the vTPM.

In this situation, you really want to ensure that the vTPM has 
absolutely 0 access to any memory it doesn't have to. Even better if you 
can ensure it stays that way (read: no way to write CR3).


> The flip side is that, assuming the vTPM is the compromised service,
> you've already got the ability to fake TPM based runtime attestation,
> so its still game over from the remote attestation point of view.  This
> leads me to conclude that it really doesn't matter where security
> critical protocols run, and the only real advantage of the ring 0/3
> separation would come into play if the SVSM had some non-security
> critical protocols and it's not clear if it ever will.


I think going forward we will have to move the UEFI Variable Runtime 
Services into SVSM as well. There is no virtual SMM mode in SEV-SNP that 
I'm aware of and trusting the host environment for UEFI Secure Boot may 
or may not be desirable.


>
>>> 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.
>> And there is definitely a lot of complexity added by supporting
>> ring3. You are essentially getting the complexity of a "real"
>> operating system.  By contrast, TDX is providing the same kind of
>> isolation with secure enclaves, but at least the base OS kernel is
>> shared.
>>
>> The expected benefit is to be able to run more complex code from
>> ring3 with a better way to handle malfunctions, faults, whatever. At
>> least that's the way I read it. So it's a way to write software in a
>> more modular way.
> Yes, but is that a benefit?  If one of the protocol modules faults, I
> think you'd rather have a hard failure of the whole confidential VM
> than a restart that gives an attacker more leeway to craft a
> compromise.


It's also about the ability to detect failure. The more guard rails you 
put in, the more likely you can identify when something goes off. 
Whether we then attempt to continue execution or consider it a fatal 
event is up to us.

The worst case would be a fully populated linear address space where any 
pointer derailing is completely undetectable.


>
>> IIUC, the ring-3 modules of the SVSM would still be at VMPL0, so
>> presumably, not accesible from host or guest. If we consider this
>> property as strong, then do we really care entrusting ring3 with
>> sensitive data?
> Well, as I said above, I think for security critical modules, it
> doesn't matter where they run, so perhaps we don't care, but equally
> there's not much security benefit to ring 0/3 separation either.
>
>>> 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).
>> I don't understand what you call "pure code". I presume you mean
>> "code that does not need to access ring0 data"?
> I was meaning a VDSO like model, where the openssl crypto code could be
> exported from ring-0 as an executable library, but the data would live
> with the corresponding consumer, so it could be used by the SVSM body
> at ring-0 with any crypto data being held at ring-0 and inaccessible to
> ring-3 consumers of the crypto code.


Have a look at this presentation, get all the way to the on-screen 
keyboard sniffer and then faithfully tell me again that you believe 
sharing code (and AES tables) is a good idea :)

https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here

I also feel like I'm missing something obvious in the conversation. 
Let's imagine the worst case for size I can think of today. In that 
case, the main SVSM code, vTPM code as well as UEFI variable store would 
duplicate (parts of) crypto libraries. Let's again imagine the worst and 
no proper LTO, so we need to link all of openssl into all 2 components 
plus the Rust based crypto which we again assume to be as large.

In this worst case scenario not sharing the code wastes less than 1MiB 
altogether. That doesn't sound like something to optimize for at all at 
this stage?


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

[Jörg Rödel]

On Thu, May 04, 2023 at 01:04:09PM -0400, James Bottomley wrote:
> 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.

It all depends on what the SVSM allows ring-3 to do, or in other
words, how the security model is implemented which locks down the ring-3
services. For example, I can see an attestation service implemented in
ring-3 as the exclusive owner of the VMPCK0 key (enforced by SVSM ring-0
code).

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

The security model is certainly not fully designed in all details, but
when comparing an all-ring-0 (with everything in one address space)
approach to a split-code model which moves functionality into separate
address spaces and less privileged execution contexts, my bet is that
the latter will always win. This is something we know already, so there
is no need to re-learn that 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).

That, in contrast, is something I would leave to evolution. We can build
the services (attestation, TPM, ...) and see if they benefit from a
shared-lib for crypto. The dynamic linking for that is certainly not
trivial, but can also be fully done in ring-3.

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

Another reason to move all of this to ring-3. Ring-3 services can be
written in C and use C libraries as needed without lowering the security
of the ring-0 rust code.

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