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

[Alexander Graf <graf@amazon.com>]

Hey James,

On 08.06.24 16:41, James Bottomley wrote:
>
> 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


That assumes you want an SVSM in the first place. I

   a) Don't think you really need to and
   b) Believe it should come from the customer, not the cloud provider, 
as it's the highest privileged piece of code in your VM


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

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


This only works if the SVSM doesn't have any security vulnerabilities. 
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?


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