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

[James Bottomley <jejb@linux.ibm.com>]

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