linux-kernel - RE: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI

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]

Date: Tue, 16 Jan 2024 12:44:38 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Samuel Ortiz <sameo@...osinc.com>, Dan Williams <dan.j.williams@...el.com>
CC: <linux-coco@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI

Samuel Ortiz wrote:
> Some confidential computing architectures (Intel TDX, ARM CCA, RISC-V
> CoVE) provide their guests with a set of measurements registers that can
> be extended at runtime, i.e. after the initial, host-initiated
> measurements of the TVM are finalized. Those runtime measurement
> registers (RTMR) are isolated from the host accessible ones but TSMs
> include them in their signed attestation reports.
> 
> All architectures supporting RTMRs expose a similar interface to their
> TVMs: An extension command/call that takes a measurement value and an
> RTMR index to extend it with, and a readback command for reading an RTMR
> value back (taking an RTMR index as an argument as well). This patch series
> builds an architecture agnostic, configfs-based ABI for userspace to extend
> and read RTMR values back. It extends the current TSM ops structure and
> each confidential computing architecture can implement this extension to
> provide RTMR support.

Hi Samuel, this looks like the right direction to me.

One of my goals at Plumbers was to explore the tension of the perception
of RTMR being a one-off (Intel-only) solution, and that the ecosystem is
otherwise best served by preserving TPM ABI momentum.

This submission clears that first concern, several vendors have an RTMR
concept. The second concern, after talking with others, is that a
soft-TPM (e.g. vtpm_proxy) backed by RTMR can support the TPM ecosystem.
Such a layer on top of this achieves TPM support for several
architectures at once which seems the right thing to do from an upstream
maintenance perspective.

I will likely have some questions about the details, but that basic
"should we do this" threshold in my view has been overcome.