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: <2d459da4-03e7-4233-9c93-cd6b88886a85@intel.com>
Date: Tue, 10 Sep 2024 13:07:25 -0500
From: "Xing, Cedric" <cedric.xing@...el.com>
To: Alexander Graf <graf@...zon.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 9/10/2024 2:47 AM, Alexander Graf wrote:
> On 09.09.24 16:55, Xing, Cedric wrote:
>> 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.
> 
You are absolute right that all MRs are the same thing, and that's why 
they are modeled in the same way at the CC guest driver level. In fact, 
if a CC guest wants to expose all MRs in their own dirs, it could set 
`TSM_MR_F_X` for all MRs and returns an error from `extend` for 
static/non-extensible ones. For example, PCR0~31 may all be exposed this 
way on Nitro. I hope this addresses your concerns.