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

["Jörg Rödel" <jroedel@suse.de>]

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