Re: Confidential Computing call May 10: RTMR ABI & TEE I/O

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2024-06-10 at 14:09 +0200, Alexander Graf wrote:
> On 08.06.24 16:41, James Bottomley wrote:
> > On Fri, 2024-06-07 at 18:05 +0200, Alexander Graf wrote:
[...]
> > > 1) Measurement purely based on initial launch measurements. If
> > > the full OS is inside an initramfs, we can provide
> > > firmware+kernel+initramfs as "seed". The CoCo env would measure
> > > everything and I have an easy path to validate authenticity of my
> > > target environment. I also have an easy path  to update the VM
> > > and then measure without replaying any event logs.
> > With an SVSM (that you're not replacing, so the initial launch
> 
> 
> That assumes you want an SVSM in the first place.

Well, yes.  This is a flexibility issue.  If you don't have a highly
privileged SVSM like entity to fix up issues and add features, you're
left with only the hardware lifecycle.

>  I
>    a) Don't think you really need to and

Most CSPs are already doing something similar to this even for non-
confidential VMs.

>    b) Believe it should come from the customer, not the cloud
> provider, as it's the highest privileged piece of code in your VM

No, the security processor firmware is the highest privilege level ...
and that doesn't come from the customer ...

The point is not that the customer should own the component and be
forced to supply it, it's that the customer should be able to inspect
it and verify the measurement corresponds to the inspected code. 
Ideally, if we get commonality of SVSMs, it becomes a singular trusted
component (like shim/grub) in the boot sequence.

> For both, the easy solution is to allow a customer to reboot into
> their own "initial launch measurement" from a currently running VM.

How, though?  The current SNP launch measurement won't change across a
kexec reboot.  If you have a mechanism that allows it to be updated
from the kernel, that will be subject to attack by a kernel exploit, so
letting a more privileged and protected entity control that seems to be
a better security model.

[...]
> > > 2) Update SVSM (or similar). Often today, you want to implement
> > > TPMs and inside a higher privileged component that is really part
> > > of the VM. To update it, you could use in-VM mechanisms, but that
> > > leaves a path where you boot with an old version -> exploit ->
> > > update to the new. If we could "reboot"/kexec into a new SVSM, we
> > > could reason about its confidentiality with a 100% guarantee.
> >  
> > This one's a bit more difficult because the initial launch
> > measurement becomes invalid if the SVSM is replaced.  What I'd
> > suggest happens here is that the SVSM reinit everything (including
> > the vTPM), then measure a "replace SVSM" record containing both the
> > old and new SVSM measurements and then do a measured boot.  That
> > way an attesting system can tie the old launch measurement to the
> > updated SVSM.
> 
> 
> This only works if the SVSM doesn't have any security
> vulnerabilities. 

In the same way that any VM kexec reboot only works if the security
processor doesn't have any vulnerabilities.  If you have a
vulnerability, either in the ASP or the SVSM you have to assess whether
it's been exploited before deciding to kexec reboot or tear down and
reinit with an updated TCB.

> If it does, you can't trust the measurement anymore and your whole 
> update path is out of the window. For CoCo, we need to make sure that
> there is a viable way for users to run secure versions of all code 
> without depending on the merit of their infrastructure provider, no?

That's not possible to guarantee in practice because of potential
vulnerabilities in other code/firmware aspects of the system regardless
of whether there's an SVSM.  The point being that you *always* have
this problem regardless of whether an SVSM is present or not.

James