[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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