linux-kernel - Re: [PATCH v3 2/5] tsm-mr: Add tsm-mr 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: <67f5f706de0f9_72052948@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 8 Apr 2025 21:26:46 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Cedric Xing <cedric.xing@...el.com>, Dan Williams
	<dan.j.williams@...el.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, <x86@...nel.org>, "H. Peter Anvin"
	<hpa@...or.com>
CC: <linux-kernel@...r.kernel.org>, <linux-coco@...ts.linux.dev>, "Dionna
 Amalie Glaze" <dionnaglaze@...gle.com>, Guorui Yu
	<guorui.yu@...ux.alibaba.com>, James Bottomley
	<James.Bottomley@...senpartnership.com>, Dan Middleton
	<dan.middleton@...ux.intel.com>, Mikko Ylinen <mikko.ylinen@...ux.intel.com>,
	Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: Re: [PATCH v3 2/5] tsm-mr: Add tsm-mr sample code

Cedric Xing wrote:
> This sample kernel module demonstrates how to make MRs accessible to user
> mode through the tsm-mr library.
> 
> Once loaded, this module registers a `miscdevice` that host a set of
> emulated measurement registers as shown in the directory tree below.
> 
> /sys/class/misc/tsm_mr_sample
> └── emulated_mr
>     ├── config_mr
>     ├── report_digest:sha512
>     ├── rtmr0:sha256
>     ├── rtmr1:sha384
>     ├── rtmr_crypto_agile:sha256
>     ├── rtmr_crypto_agile:sha384
>     └── static_mr:sha384
> 
> Among the MRs in this example:
> 
> - `config_mr` demonstrates a hashless MR, like MRCONFIGID in Intel TDX or
>   HOSTDATA in AMD SEV.
> - `static_mr` demonstrates a static MR. The suffix `:sha384` indicates its
>   value is a sha384 digest.
> - `rtmr0` is an RTMR with `TSM_MR_F_WRITABLE` **cleared**, preventing
>   direct extensions; as a result, the attribute `rtmr0:sha256` is
>   read-only.
> - `rtmr1` is an RTMR with `TSM_MR_F_WRITABLE` **set**, permitting direct
>   extensions; thus, the attribute `rtmr1:sha384` is writable.
> - `rtmr_crypto_agile` demonstrates a "single" MR that supports multiple
>   hash algorithms. Each supported algorithm has a corresponding digest,
>   usually referred to as a "bank" in TCG terminology. In this specific
>   sample, the 2 banks are aliased to `rtmr0` and `rtmr1`, respectively.
> - `report_digest` contains the digest of the internal report structure
>   living in this sample module's memory. It is to demonstrate the use of
>   the `TSM_MR_F_LIVE` flag. Its value changes each time an RTMR is
>   extended.
> 
> Signed-off-by: Cedric Xing <cedric.xing@...el.com>
[..]
> +static struct tsm_measurements emulated_mr = {
> +	.name = "emulated_mr",

I think the convention should be that all consumers use a common name
for this common ABI, similar to a sysfs-class. So, I would say set the
name to "measurement_registers" inside tsm_mr_create_attribute_group(),
and make the "custom name" or "no-name" case an isolated corner case.

Other than that, thanks for taking the time to build this sample it
makes the reviewing the implementation easier and allows for some ABI
testing.