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

[Alexander Graf <graf@amazon.com>]

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