Message-ID: <d49a9768-fc9c-4df7-ba11-5b25470f6feb@amazon.com>
Date: Tue, 10 Sep 2024 09:47:52 +0200
From: Alexander Graf <graf@...zon.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Dan Williams
	<dan.j.williams@...el.com>, Samuel Ortiz <sameo@...osinc.com>, "James
 Bottomley" <James.Bottomley@...senPartnership.com>, Lukas Wunner
	<lukas@...ner.de>, Dionna Amalie Glaze <dionnaglaze@...gle.com>, Qinkun Bao
	<qinkun@...gle.com>, Mikko Ylinen <mikko.ylinen@...ux.intel.com>, "Kuppuswamy
 Sathyanarayanan" <sathyanarayanan.kuppuswamy@...ux.intel.com>
CC: <linux-kernel@...r.kernel.org>, <linux-coco@...ts.linux.dev>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs


On 09.09.24 16:55, Xing, Cedric wrote:
> Hi Alex,
>
> Thanks for you comments!
>
> On 9/8/2024 12:37 PM, Alexander Graf wrote:
>> Hey Cedric,
>>
>> On 08.09.24 06:56, Cedric Xing wrote:
>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>> and is
>>> largely a continuation of Samuel Ortiz’s previous work on the RTMR ABI
>>> [1].
>>>
>>> This patch series adds a unified interface to TSM core for confidential
>>> computing (CC) guest drivers to provide access to measurement
>>> registers (MRs),
>>> which are essential for relying parties (RPs) to verify the integrity
>>> of the
>>> computing environment. The interface is structured around
>>> `struct tsm_measurement_provider`, which holds an array of
>>> `struct tsm_measurement_register` and includes operations for 
>>> reading and
>>> updating MRs.
>>>
>>> The MRs come in two varieties: static and runtime. Static MRs are
>>> determined at
>>> the TEE VM (TVM) build time and capture the initial memory image or the
>>> configuration/policy specified by the TVM's owner. In contrast,
>>> Runtime MRs
>>> (RTMRs) start with known values, such as all zeros, at TVM build time
>>> and are
>>> extended with measurements of loaded code, data, configuration, or
>>> executed
>>> actions by the TVM guest during runtime.
>>
>>
>> Is there a particular reason to treat runtime and static measurements
>> separately? In Nitro Enclaves (which I still need to add tsm integration
>> for), both are simply NSM PCRs. "Static" measurements get locked by the
>> initial boot code. "Runtime" measurements can get locked by guest code
>> later in the boot process. But technically, both are the same type of
>> measurement.
>>
> My apologies for the confusion! They are in fact treated in the same way
> from the CC guest driver's perspective.


I'm not worried about the driver's perspective to be honest; I'm much 
more interested in the user space ABI and to ensure it's consistent and 
flexible :).


> Here I meant to describe that static and runtime MRs have different
> properties (like "locked" as you mentioned) so in order to treat them in
> the same way, we'd have to define the properties in code (i.e., `enum
> tsm_measurement_register_flag` in include/linux/tsm.h).
>
>> In fact, other attributes like an additional "hash_algo" to the
>> measurement itself can be useful in general. If the underlying
>> infrastructure allows for a generic event log mechanism, having that
>> easily available here is useful too.
>>
> `hash_algo` is indeed a member of `struct tsm_measurement_register`.
>
>> So I don't really understand why we would treat static and runtime
>> measurements differently. Can't we just make all of them directories and
>> indicate whether they are (im-)mutable via a file?
>>
> Distinguishing them in the user interface makes enumeration of RTMRs
> easier. Also, there are RTMR specific artifacts that static MRs don't
> have. The most obvious is the `event_log`. `hash_algo` is less obvious
> but it is in fact applicable to RTMRs only (the only thing that a static
> MR has is its value). Adding those to static MRs would confuse users.


I think that this statement is looking too much at the problem with TDX 
glasses on. Conceptually, measurements can happen at any time by any 
component and then get locked going forward. Let's look a bit at what 
different solutions do:

TDX

static - special registers that get written by the secure module and are 
locked at launch (?); SHA256? No event log; order defined by platform.
dynamic - special registers that are mutable at runtime

SEV-SNP

static - launch digest generated by ASP at launch time using a SEV-SNP 
specific algorithm. No event log; order defined by platform.
dynamic - not specified, would be implemented by an SVSM

Nitro Enclaves

static - PCR0-15 get calculated and then locked by the boot loader. 
SHA384. No event log; mechanics to reproduce are defined in docs.
dynamic - PCR16-31 are up for customer use and can be locked at any 
later stage. SHA384. Event log is undefined and up to customer code.


All static calculations are based on some algorithm. Yes, the algorithm 
isn't necessarily a standard digest, but they can all have a name. I can 
also absolutely see how any of the solutions above gain event log 
support for static or dynamic measurements. At the end of the day, an 
event log for static measurements is just a matter of writing it out at 
launch time.

So what I'm trying to say is: In the user space ABI (file system 
layout), please treat static and dynamic registers identically. There 
really is no difference between them apart from the fact that some are 
read-only and others are read-write.


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

Powered by blists - more mailing lists