linux-kernel - Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs

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: Sun, 21 Jan 2024 18:13:28 -0800
From: Qinkun Bao <qinkun@...gle.com>
To: Samuel Ortiz <sameo@...osinc.com>,
 jiewen.yao@...el.com,
 ken.lu@...el.com
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
 Dan Williams <dan.j.williams@...el.com>,
 linux-coco@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs



> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@...osinc.com> wrote:
> 
> On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan wrote:
>> 
>> On 1/16/24 5:24 PM, Dan Williams wrote:
>>> Kuppuswamy Sathyanarayanan wrote:
>>>> On 1/14/24 2:35 PM, Samuel Ortiz wrote:
>>>>> Many user space and internal kernel subsystems (e.g. the Linux IMA)
>>>>> expect a Root of Trust for Storage (RTS) that allows for extending
>>>>> and reading measurement registers that are compatible with the TCG TPM
>>>>> PCRs layout, e.g. a TPM. In order to allow those components to
>>>>> alternatively use a platform TSM as their RTS, a TVM could map the
>>>>> available RTMRs to one or more TCG TPM PCRs. Once configured, those PCR
>>>>> to RTMR mappings give the kernel TSM layer all the necessary information
>>>>> to be a RTS for e.g. the Linux IMA or any other components that expects
>>>>> a TCG compliant TPM PCRs layout.
>>>>> 
>>>>> TPM PCR mappings are configured through configfs:
>>>>> 
>>>>> // Create and configure 2 RTMRs
>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr0
>>>>> mkdir /sys/kernel/config/tsm/rtmrs/rtmr1
>>>>> echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index
>>>>> echo 1 > /sys/kernel/config/tsm/rtmrs/rtmr1/index
>>>>> 
>>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8
>>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map
>>>>> 
>>>>> // Map RTMR 1 to PCRs 16, 17 and 18
>>>>> echo 16-18 > /sys/kernel/config/tsm/rtmrs/rtmr1/tcg_map
>>>> Any information on how this mapping will be used by TPM or IMA ?
>>>> 
>>>> RTMR to PCR mapping is fixed by design, right? If yes, why allow
>>>> user to configure it. We can let vendor drivers to configure it, right?
>>> I assume the "vendor driver", that publishes the RTMR to the tsm-core,
>>> has no idea whether they will be used for PCR emulation, or not. The TPM
>>> proxy layer sitting on top of this would know the mapping of which RTMRs
>>> are recording a transcript of which PCR extend events.
>> 
>> My thinking is, since this mapping is ARCH-specific information
>> and fixed by design, it makes more sense to hide this detail in the
>> vendor driver than letting userspace configure it. If we allow users to
>> configure it, there is a chance for incorrect mapping.
> 
> I think I agree with the fact that letting users configure that mapping
> may be error prone. But I'm not sure this is an architecture specific
> mapping, but rather a platform specific one. I'd expect the guest firmware
> to provide it through e.g. the MapPcrToMrIndex EFI CC protocol.
> 
> So I agree I should remove the user interface for setting that mapping,
> and pass it from the provider capabilities instead. It is then up to the
> provider to choose how it'd build that information (hard coded, from
> EFI, etc).

The UEFI specification has defined the mapping relationship between the 
TDX RTMR and TPM PCRs (See https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension). The current RTMR implementation in the boot loader 
is “hooked” in the implementation for the TPM. 

When the bootloader needs to extend the PCR value, it calls 
`map_pcr_to_mr_index`  to retrieve the corresponding RTMR index and 
then extends the RTMR. Considering this behavior, I don’t think we should
allow users to configure the mappings between the PCR and RTMR. (See https://github.com/rhboot/shim/pull/485/files).

Add Jiewen (owner of the RTMR changes in the firmware) and Ken (
owner of the RTMR changes in the boot loader) for the visibility.

> 
>> Regarding the TPM proxy, I am still not clear how it is going to use
>> this mapping. If we want to provide TPM like feature, it needs a
>> special kernel TPM driver, right? Even if we enable TPM support
>> with RTMR, I assume it can only support pcr_extend().
> 
> Extend and read, yes.
> 
>> Other TPM
>> features should be disabled. If yes, since we already have this ABI
>> for measurement extension, why again support it via TPM or did
>> I misunderstand the use case.
> 
> I am not sure the TPM compatibility is always needed, but for subsystems
> (like e.g. IMA) that look for a TPM as their root of trust for storage,
> providing the extend+read ABI and the PCR mapping should be sufficient.
> 
> Cheers,
> Samuel.
> 
>