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

[Alexander Graf <graf@amazon.com>]

Hi Elena,

On 12.06.24 13:19, Reshetova, Elena 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 new
>>> CoCo VM on the same platform? I guess the difference would be the absence
>>> of 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.
>>
>> 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.
> I think I am still confused on the problem statement. You are saying that
> CoCo customers should be able to update their coco VMs (with SVSM or without)
> without CSP intervention, which fully makes sense. But at the same time
> you want to do it without a coco VM reboot (which is the easiest way of
> solving this with existing means), but via some kind of fast runtime kexec
> of the whole machine? Why? If customer is updating its coco VM, it should
> be ok for them to save data and take a full reboot, why not?
> I do agree that there is another problem currently with the fact how hard
> it is to reason about the state of the full SW stack of CoCo VM (many
> measurements, many updated components, long event log, things that
> might not get measured, etc.), but it seems a different problem to the
> one you are stating or?


I *want* a full coco VM reboot. But I also want the pre-reboot VM to 
provide the initial launch data for the post-reboot VM.

The typical reboot case (CoCo or not) is that a VM always starts with 
initial launch data that the VM provider provisions. That means again 
the "typical" path is that you boot with initial launch data that your 
VM provider dictates: Either explicitly (like in EC2, where we give you 
a publicly, reproducibly built OVMF binary) or implicitly through a 
selection of "known good launch data" you can choose from.

You can in theory even set up side channels from the customer to your 
provider to upload new "known good launch data". But that's complicated 
for all layers because it requires API privileges the VM may not 
otherwise require and it means you need to store and transfer that data 
across the control plane of the target launch stack.

My proposal above was to do a reboot, but instead of seeding the 
"initial launch data" from the provider, you just seed it from the 
pre-reboot environment. That way customers can reboot into any version 
of code they like and 100% own their measurements in a VM provider 
agnostic way.

Kexec comes into play because from a customer experience, the flow 
should ideally be as easy as saying "kexec me into this new firmware". I 
say kexec here because it's the closest analogy we have in Linux to 
"reboot, but with a pre-reboot provided payload". The fact that kexec 
doesn't perform a reboot today but simulates it using fancy stunts is an 
implementation detail IMHO.


Alex




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597