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

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

On Fri, 2024-06-07 at 18:05 +0200, Alexander Graf wrote:
> 
> On 07.06.24 16:46, Reshetova, Elena wrote:
> > > Hi Dan,
> > > 
> > > On 03.05.24 21:55, Dan Middleton wrote:
> > > > Hi
> > > > Next Friday, May 10th at 9am PDT, we have a Confidential
> > > > Computing devsec / BoF / Discussion Group / SIG call. Everyone
> > > > is welcome.
> > > > 
> > > > Tentative agenda includes RTMR ABI v3 direction and TEE I/O
> > > > next steps.
> > > 
> > > I haven't seen an email for today's call, so let me throw my
> > > topic suggestion here:
> > > 
> > > I would like to talk about "confidential kexec" today: A kexec
> > > mechanism that allows you to destroy the confidential VM you're
> > > in and recreate a new one based on a payload of the old one. With
> > > that, we would have a very easy and clean mechanism to bootstrap
> > > a VM into a fully measured  new execution stack.
> >  
> > Interesting topic, I am curious of the requirements!
> > Sounds like you want a local fast migration, i.e. a migration to a
> > newCoCo VM on the same platform? I guess the difference would be
> > the absenceof the online migration phase since you are probably ok
> > stopping the original CoCo VM first.
> 
> 
> Almost. I basically want the VM to be able to provide a new early 
> measurement. So the opposite of migration: With migration, I want to 
> preserve previous state. Here, the main motivation is to get rid of
> any previous state except the new "seed" for the target VM.
> 
> There are 2 main use cases for this:
> 
> 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
measurement remains valid) this one is easy: it can reinit everything
(including the vTPM) and redo a measured boot.  So here you have
exactly the same measurements as though it were a clean boot. 

> 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.

James