linux-kernel - Re: [PATCH RFC 3/3] tsm: Add TVM Measurement Sample Code

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: <529689b46df6a99a4a284192c461d16f7bfbb9f0.camel@HansenPartnership.com>
Date: Sat, 14 Sep 2024 13:10:33 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Dan Williams
 <dan.j.williams@...el.com>, Samuel Ortiz <sameo@...osinc.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 3/3] tsm: Add TVM Measurement Sample Code

On Sat, 2024-09-14 at 11:36 -0500, Xing, Cedric wrote:
> On 9/12/2024 7:28 AM, James Bottomley wrote:
> > On Sat, 2024-09-07 at 23:56 -0500, 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
> > >      ├── full_report
> > >      ├── report_digest
> > >      ├── rtmr0
> > >      │   ├── append_event
> > >      │   ├── digest
> > >      │   ├── event_log
> > >      │   └── hash_algo
> > >      ├── rtmr1
> > >      │   ├── append_event
> > >      │   ├── digest
> > >      │   ├── event_log
> > >      │   └── hash_algo
> > >      ├── static_mr
> > >      └── user_data
> > 
> > I'm not sure this is the best structure to apply to logs with
> > multiple banks (hash algorithms).  There needs to be a way to get
> > the same registers measurement for each bank, but the log should
> > sit above that (appending should extend all active banks)
> > 
> > How about
> > 
> > /sys/kernel/tsm/
> > └──<measurement type>
> >     ├──reg0
> >     │   ├── <log format>
> >     │   │   ├── append_event
> >     │   │   └── event_log
> >     │   ├── <hash algo>
> >     │  ...  └── digest
> >     ...
> > 
> > That way it supports multiple log formats (would be the job of the
> > log extender to ensure compatibility) and multiple banks.
> > 
> I have considered this before. But I'm not sure how to
> (define/describe criteria to) match an MR with its log format.

This is already defined for every existing log format ... why would you
have to define it again?

>  Also, MRs are arch dependent and may also vary from gen to gen. I'm
> afraid this might bring in more chaos than order.

I think I understand this. All measurement registers are simply
equivalent to PCRs in terms of the mathematical definition of how they
extend.  Exactly what measurements go into a PCR and how they are
logged is defined in various standards.  The TCG ones are fairly fixed
now, but if Intel wants to keep redefining the way its measurements
work, the logical thing to do is tie this to a version number and make
measuring the version the first log entry so the tools know how to
differentiate.

James