Re: [PATCH RFC v2 2/2] tsm: Add TVM Measurement Sample Code

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2024-11-04 at 19:40 +1100, Alexey Kardashevskiy wrote:
> On 1/11/24 03:50, Cedric Xing wrote:
> > This sample kernel module demonstrates how to make MRs accessible
> > to user mode through TSM.
> > 
> > Once loaded, this module registers a virtual measurement provider
> > with the TSM core and will result in the directory tree below.
> > 
> > /sys/kernel/tsm/
> > └── measurement-example
> >      ├── config_mr
> >      │   ├── digest
> >      │   └── hash_algo
> 
> Do we actually need this many nodes? A digest is 64bytes long (or 128
> chars), hash_algo is lot less, "config_mr" could just print 
> human-readable 2 lines (one with the algo, one with the digest), just
> like many other things in sysfs.

Actually, that's not supposed to be like anything in sysfs.  Attributes
are supposed to have one value per file:

https://docs.kernel.org/filesystems/sysfs.html#attributes

However, as I keep saying, this structure doesn't support systems, like
the TPM, which can have multiple hashes per measurement register, so I
still think the structure should be

<measurement type>/<pcr number>/<hash>/digest

to allow for that.  I even think even Intel will be forced to use agile
cryptography one day: even if Shor's algorithm isn't realised post
quantum, the hash and curve will have to expand to at least 512 bits
and there's bound to be several candidates plus backwards compatibility
problems.

[...]
> It looks that /sys/kernel/tsm/full_report is a binary concatenation
> of 6 digests, with no hash_algo and no hint which digest is which,
> hardly a "structure". I do understand it is an example though :)

That doesn't sound right: the rtmrs can be extended post launch, so
this should be some type of log of all the post launch measurements to
allow the relying system to examine the events as well as the final
value.

James