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: <66e2298eb64ec_3263b2945@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 11 Sep 2024 16:36:46 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Jean-Philippe Brucker
	<jean-philippe@...aro.org>
CC: 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>, <linux-kernel@...r.kernel.org>,
	<linux-coco@...ts.linux.dev>, <suzuki.poulose@....com>,
	<sami.mujawar@....com>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs

Xing, Cedric wrote:
[..]
> With regard to the location of the MR tree, we picked sysfs because the 
> MRs (and associated logs) are global and fit more into the semantics of 
> sysfs than configfs. Dan W. and I are also considering moving both 
> report/ and measurement/ trees into securityfs. It'll be highly 
> appreciated if you (and Alex, and everyone) can share your insights.

I would only expect this new measurement interface is suitable for
considering securityfs. The tsm_report uAPI is already baked and has a
need for the multi-instance support of configfs.

The rationale for RTMR measurements in securityfs is because the IMA
measurement uAPI already lives there. So it is more about following
precedent for co-locating a new ASCII RTMR measurement log in the same
filesystem that provides ima/ascii_runtime_measurements.

A multi-instance interface for virtual RTMRs might be suitable to live
in configfs alongside reports/, and use this native singleton log as a
backend.