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

[Xing, Cedric]

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.