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

[Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>]

On 1/21/24 8:31 AM, Samuel Ortiz 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).
>
>> 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.

My question is, do we even want to expose the PCR-RTMR mapping to the
user? Even if we want to support IMA with RTMR, I think the mapping
needs to be done in the kernel and the userspace does not need to
worry about it.

> Cheers,
> Samuel.
>
-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer