Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

["Xing, Cedric" <cedric.xing@intel.com>]

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.

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.

-Cedric