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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10ffa4f1-e3f9-4b7d-9a6f-e4dd843f6d44@amazon.com>
Date: Sun, 8 Sep 2024 19:37:32 +0200
From: Alexander Graf <graf@...zon.com>
To: Cedric Xing <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

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.

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.

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?

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