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
