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

[Alexander Graf <graf@amazon.com>]

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.


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