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: <b20a4dc2-2794-46a9-b3d5-41e06ce22e34@intel.com>
Date: Mon, 22 Jan 2024 14:12:23 -0800
From: "Xing, Cedric" <cedric.xing@...el.com>
To: Dan Williams <dan.j.williams@...el.com>, Samuel Ortiz
	<sameo@...osinc.com>, <biao.lu@...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



On 1/21/2024 11:15 AM, Dan Williams wrote:
> Samuel Ortiz wrote:
>> 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).
> 
> Another observation after chatting with my colleague Cedric is that the
> TPM layer that builds on RTMR can maintain an event log that forks from
> the RTMR log. I.e. instead of the TPM event log containig pre-OS events
> starting from 0, it would start from a golden point in the RTMR
> measurements.
> 
That's right. What's needed in verification is the full history of how a 
measurement register's value was transitioned from A->B, which could be 
segmented as A->X then X->B and stored in separate event logs. Those 
event logs don't have to be maintained by the same entity or in the same 
format.