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

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

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