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]

Message-ID: <Za1eXWiKPQp//1CO@vermeer>
Date: Sun, 21 Jan 2024 19:11:41 +0100
From: Samuel Ortiz <sameo@...osinc.com>
To: biao.lu@...el.com
Cc: dan.j.williams@...el.com, linux-coco@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI

On Thu, Jan 18, 2024 at 11:35:15AM +0800, biao.lu@...el.com wrote:
> 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
> The ABI does not include eventlog, but eventlog is usually used with RTMR.
> What do you think about how to implement eventlog?

Since the event log is typically maintained in the firmware and not in
the TSM itself, I don't think we should expose e.g. an event log
extension ABI through the config-tsm one.
We could decide to check for an EFI CC protocol availability and extend
the event log when any RTMR gets extended, and that would be an
internal, not userspace visible operation. I'm not sure that this
would scale well with e.g. IMA (a lot more events than pre-OS boot
afaik).

Cheers,
Samuel.