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

  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

Signed-off-by: Samuel Ortiz <sameo@rivosinc.com>
---
 drivers/virt/coco/tsm.c | 60 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)
  

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?


>
> Signed-off-by: Samuel Ortiz <sameo@rivosinc.com>
> ---
>  drivers/virt/coco/tsm.c | 60 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
>
> diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
> index 15b67d99fd54..f35f91cb7bd3 100644
> --- a/drivers/virt/coco/tsm.c
> +++ b/drivers/virt/coco/tsm.c
> @@ -472,8 +472,68 @@ static ssize_t tsm_rtmr_index_show(struct config_item *cfg,
>  }
>  CONFIGFS_ATTR(tsm_rtmr_, index);
>  
> +static ssize_t tsm_rtmr_tcg_map_store(struct config_item *cfg,
> +				      const char *buf, size_t len)
> +{
> +	struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
> +	int i, pcrs[TPM2_PLATFORM_PCR + 1];
> +
> +	get_options(buf, ARRAY_SIZE(pcrs), pcrs);
> +
> +	if (pcrs[0] > TPM2_PLATFORM_PCR - 1)
> +		return -EINVAL;
> +
> +	guard(rwsem_write)(&tsm_rwsem);
> +	/* Check that the PCR list is valid  */
> +	for (i = 0; i < pcrs[0]; i++) {
> +		/* It must be a valid TPM2 PCR number */
> +		if (pcrs[i] > TPM2_PLATFORM_PCR - 1)
> +			return -EINVAL;
> +
> +		/* If another RTMR maps to this PCR, the list is discarded */
> +		if (tsm_rtmrs->tcg_map[pcrs[i + 1]] &&
> +		    tsm_rtmrs->tcg_map[pcrs[i + 1]] != rtmr_state)
> +			return -EBUSY;
> +	}
> +
> +	for (i = 0; i < pcrs[0]; i++)
> +		tsm_rtmrs->tcg_map[pcrs[i + 1]] = rtmr_state;
> +
> +	return len;
> +}
> +
> +static ssize_t tsm_rtmr_tcg_map_show(struct config_item *cfg,
> +				     char *buf)
> +{
> +	struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
> +	unsigned int nr_pcrs = ARRAY_SIZE(tsm_rtmrs->tcg_map), i;
> +	unsigned long *pcr_mask;
> +	ssize_t len;
> +
> +	/* Build a bitmap mask of all PCRs that this RTMR covers */
> +	pcr_mask = bitmap_zalloc(nr_pcrs, GFP_KERNEL);
> +	if (!pcr_mask)
> +		return -ENOMEM;
> +
> +	guard(rwsem_read)(&tsm_rwsem);
> +	for (i = 0; i < nr_pcrs; i++) {
> +		if (tsm_rtmrs->tcg_map[i] != rtmr_state)
> +			continue;
> +
> +		__set_bit(i, pcr_mask);
> +	}
> +
> +	len = bitmap_print_list_to_buf(buf, pcr_mask, nr_pcrs, 0,
> +				       nr_pcrs * 3 /* 2 ASCII digits and one comma */);
> +	bitmap_free(pcr_mask);
> +
> +	return len;
> +}
> +CONFIGFS_ATTR(tsm_rtmr_, tcg_map);
> +
>  static struct configfs_attribute *tsm_rtmr_attrs[] = {
>  	&tsm_rtmr_attr_index,
> +	&tsm_rtmr_attr_tcg_map,
>  	NULL,
>  };
>
  

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. 

For IMA the situation is different because that can be a kernel internal
configuration flow without need to involve userspace.
  

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.

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(). 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.

>
> For IMA the situation is different because that can be a kernel internal
> configuration flow without need to involve userspace.
>
  

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.

Cheers,
Samuel.
  

> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.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.
> 
>
  

Comment below:

> -----Original Message-----
> From: Qinkun Bao <qinkun@google.com>
> Sent: Monday, January 22, 2024 10:13 AM
> To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> Lu, Ken <ken.lu@intel.com>
> Cc: Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J
> <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux-
> kernel@vger.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@rivosinc.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.

I think the mapping should be static and determined by the hardware architecture.

Allowing user to configure the mapping just adds complexity and confusing. For example, the user must understand clearly on what is Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, what is the best way to map it.

It also adds complexity to the verifier. For example, the verifier must understand how a user configure the mapping, then get the expected measurement register value.

I believe that hiding detail is a better way to avoid those complexity, and make it easy to use.

Do we have some real use cases that a user MUST configure the mapping?

> 
> >
> >> 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.
> >
> >
  

On Sun, Jan 21, 2024 at 06:09:19PM -0800, Qinkun Bao wrote:
> 
> 
> > On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.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 <https://github.com/rhboot/shim/pull/485/files>).

Just to be clear: I agree with that and I am going to send a v2 with
that user interface removed.
However I believe that we still need the TSM framework to know about
these mappings and the question is where does the kernel get it from?

You're suggesting that for TDX these mappings are architecturally
defined, as described by the UEFI spec. For other architectures (CCA,
CoVE) they are not (yet), so I'm suggesting to leave each TSM provider
backend decide how the PCR to RTMR mapping should be built/fetched and
provide it to the TSM framework through the tsm_capabilities structure
that this patchset introduces. The TDX implementation could decide to
hardcode it to the UEFI specification.

Cheers,
Samuel.
  

Hi Jiewen,

On Mon, Jan 22, 2024 at 02:23:02AM +0000, Yao, Jiewen wrote:
> Comment below:
> 
> > -----Original Message-----
> > From: Qinkun Bao <qinkun@google.com>
> > Sent: Monday, January 22, 2024 10:13 AM
> > To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> > Lu, Ken <ken.lu@intel.com>
> > Cc: Kuppuswamy Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J
> > <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux-
> > kernel@vger.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@rivosinc.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.
> 
> I think the mapping should be static and determined by the hardware architecture.
> 
> Allowing user to configure the mapping just adds complexity and confusing. For example, the user must understand clearly on what is Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have, what is the best way to map it.
> 
> It also adds complexity to the verifier. For example, the verifier must understand how a user configure the mapping, then get the expected measurement register value.
> 
> I believe that hiding detail is a better way to avoid those complexity, and make it easy to use.

I agree.

> Do we have some real use cases that a user MUST configure the mapping?

Not that I know of, and I will remove that userspace interface in v2 of this patchset.

Cheers,
Samuel.
  

On 1/21/24 11:46 PM, Samuel Ortiz wrote:
> On Sun, Jan 21, 2024 at 06:09:19PM -0800, Qinkun Bao wrote:
>>
>>> On Jan 21, 2024, at 8:31 AM, Samuel Ortiz <sameo@rivosinc.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 <https://github.com/rhboot/shim/pull/485/files>).
> Just to be clear: I agree with that and I am going to send a v2 with
> that user interface removed.
> However I believe that we still need the TSM framework to know about
> these mappings and the question is where does the kernel get it from?
>
> You're suggesting that for TDX these mappings are architecturally
> defined, as described by the UEFI spec. For other architectures (CCA,
> CoVE) they are not (yet), so I'm suggesting to leave each TSM provider
> backend decide how the PCR to RTMR mapping should be built/fetched and
> provide it to the TSM framework through the tsm_capabilities structure
> that this patchset introduces. The TDX implementation could decide to
> hardcode it to the UEFI specification.

Agree. Lets leave it to TSM vendor drivers to provide this
mapping.


> Cheers,
> Samuel.
  

Yao, Jiewen wrote:
> Comment below:
> 
> > -----Original Message-----
> > From: Qinkun Bao <qinkun@google.com>
> > Sent: Monday, January 22, 2024 10:13 AM
> > To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> > Lu, Ken <ken.lu@intel.com>
> > Cc: Kuppuswamy Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J
> > <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux-
> > kernel@vger.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@rivosinc.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.
> 
> I think the mapping should be static and determined by the hardware architecture.
> 
> Allowing user to configure the mapping just adds complexity and
> confusing. For example, the user must understand clearly on what is
> Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have,
> what is the best way to map it.
> 
> It also adds complexity to the verifier. For example, the verifier
> must understand how a user configure the mapping, then get the
> expected measurement register value.

I agree with this, what I have a problem with is that this:

https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension

..is vendor specific, especially when the kernel enabling is being
targeted as cross-vendor.

So, yes, the mapping should be allowed to specified by the low-level
driver, but at the same time every vendor should not reinvent their own
enumeration method when we have EFI for that.

In other words Linux should enforce unification across vendors and
consider waiting until the RTMR enumeration is promoted out of the
vendor specific section to a cross vendor standard.
  

On 1/22/2024 12:10 PM, Dan Williams wrote:
> Yao, Jiewen wrote:
>> Comment below:
>>
>>> -----Original Message-----
>>> From: Qinkun Bao <qinkun@google.com>
>>> Sent: Monday, January 22, 2024 10:13 AM
>>> To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen <jiewen.yao@intel.com>;
>>> Lu, Ken <ken.lu@intel.com>
>>> Cc: Kuppuswamy Sathyanarayanan
>>> <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J
>>> <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux-
>>> kernel@vger.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@rivosinc.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.
>>
>> I think the mapping should be static and determined by the hardware architecture.
>>
>> Allowing user to configure the mapping just adds complexity and
>> confusing. For example, the user must understand clearly on what is
>> Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have,
>> what is the best way to map it.
>>
>> It also adds complexity to the verifier. For example, the verifier
>> must understand how a user configure the mapping, then get the
>> expected measurement register value.
> 
> I agree with this, what I have a problem with is that this:
> 
> https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-domain-extension
> 
> ...is vendor specific, especially when the kernel enabling is being
> targeted as cross-vendor.
> 

I have the same concern.

> So, yes, the mapping should be allowed to specified by the low-level
> driver, but at the same time every vendor should not reinvent their own
> enumeration method when we have EFI for that.
> 

Given PCR->RTMR mapping is static, I just wonder why it needs to be kept 
in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that 
TDX quotes are never TPM quotes, applications used to extend PCRs would 
have to be changed/recompiled. Then wouldn't it suffice to define the 
mappings as macros in an architecture specific header file?
  

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.
>
  

Xing, Cedric wrote:
[..]
> > So, yes, the mapping should be allowed to specified by the low-level
> > driver, but at the same time every vendor should not reinvent their own
> > enumeration method when we have EFI for that.
> 
> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept 
> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that 
> TDX quotes are never TPM quotes, applications used to extend PCRs would 
> have to be changed/recompiled. Then wouldn't it suffice to define the 
> mappings as macros in an architecture specific header file?

I think something is wrong if applications are exposed to the PCR->RTMR
mapping thrash. I would hope / expect that detail is hidden behind a TPM
proxy layer sitting in front of this mapping on behalf of TPM-client
applications.
  

> -----Original Message-----
> From: Xing, Cedric <cedric.xing@intel.com>
> Sent: Tuesday, January 23, 2024 5:59 AM
> To: Williams, Dan J <dan.j.williams@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Qinkun Bao <qinkun@google.com>; Samuel Ortiz
> <sameo@rivosinc.com>; Lu, Ken <ken.lu@intel.com>
> Cc: Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@linux.intel.com>; linux-coco@lists.linux.dev;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs
> 
> 
> 
> On 1/22/2024 12:10 PM, Dan Williams wrote:
> > Yao, Jiewen wrote:
> >> Comment below:
> >>
> >>> -----Original Message-----
> >>> From: Qinkun Bao <qinkun@google.com>
> >>> Sent: Monday, January 22, 2024 10:13 AM
> >>> To: Samuel Ortiz <sameo@rivosinc.com>; Yao, Jiewen
> <jiewen.yao@intel.com>;
> >>> Lu, Ken <ken.lu@intel.com>
> >>> Cc: Kuppuswamy Sathyanarayanan
> >>> <sathyanarayanan.kuppuswamy@linux.intel.com>; Williams, Dan J
> >>> <dan.j.williams@intel.com>; linux-coco@lists.linux.dev; linux-
> >>> kernel@vger.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@rivosinc.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.
> >>
> >> I think the mapping should be static and determined by the hardware
> architecture.
> >>
> >> Allowing user to configure the mapping just adds complexity and
> >> confusing. For example, the user must understand clearly on what is
> >> Intel-TDX/AMD-SEV/ARM-CCA/RISCV-CoVE, how many registers they have,
> >> what is the best way to map it.
> >>
> >> It also adds complexity to the verifier. For example, the verifier
> >> must understand how a user configure the mapping, then get the
> >> expected measurement register value.
> >
> > I agree with this, what I have a problem with is that this:
> >
> > https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust-
> domain-extension
> >
> > ...is vendor specific, especially when the kernel enabling is being
> > targeted as cross-vendor.
> >
> 
> I have the same concern.

May I know what the definition of "targeted as cross-vendor"?
And what exactly the concern or problem is?
Please enlighten me on that.

> 
> > So, yes, the mapping should be allowed to specified by the low-level
> > driver, but at the same time every vendor should not reinvent their own
> > enumeration method when we have EFI for that.
> >
> 
> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept
> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that
> TDX quotes are never TPM quotes, applications used to extend PCRs would
> have to be changed/recompiled. Then wouldn't it suffice to define the
> mappings as macros in an architecture specific header file?

My comment is "Please don’t let user application (ring 3) indicate the mapping". It will cause big problem if different user applications use different mapping. I see no benefit but confusion.
I have no comment on how kernel module (ring 0) indicates the mapping. It can be static in kernel or by a driver. I don’t have strong opinion here.
  

On 1/22/2024 2:32 PM, Dan Williams wrote:
> Xing, Cedric wrote:
> [..]
>>> So, yes, the mapping should be allowed to specified by the low-level
>>> driver, but at the same time every vendor should not reinvent their own
>>> enumeration method when we have EFI for that.
>>
>> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept
>> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that
>> TDX quotes are never TPM quotes, applications used to extend PCRs would
>> have to be changed/recompiled. Then wouldn't it suffice to define the
>> mappings as macros in an architecture specific header file?
> 
> I think something is wrong if applications are exposed to the PCR->RTMR
> mapping thrash. I would hope / expect that detail is hidden behind a TPM
> proxy layer sitting in front of this mapping on behalf of TPM-client
> applications.

Hi Dan,

My apology for the confusion! I think we are talking about 2 different 
scenarios - (1) this patch alone; and (2) this patch + vTPM.

Scenario 1: This patch provides RTMR access only. My assumption is, 
there are existing application (and/or kernel modules) that extend to 
PCRs today and would like to work in TDs where only RTMRs are available. 
Changes are of course necessary in those applications as TPMs/PCRs are 
no longer available, but from security perspective they would like to 
keep the same activity log and just change to use RTMRs (in lieu of 
PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and 
must be agreed upon by all those applications and relying parties. IIUC, 
this is the intention of having PCR->RTMR mapping config maintained by 
the kernel, as proposed by Sam O. originally.

Scenario 2: A vTPM is implemented on top of this patch, in which case 
the existing applications don't have to change as they can continue 
extending to the same PCRs, which will then be emulated by the 
underlying vTPM implementation. PCR->RTMR mapping in this scenario is 
obviously internal to the vTPM and I agree with you completely that it 
should be hidden inside the vTPM.

My comment in my previous email was regarding Scenario 1. I hope the 
clarification above helps.

-Cedric
  

Xing, Cedric wrote:
> On 1/22/2024 2:32 PM, Dan Williams wrote:
> > Xing, Cedric wrote:
> > [..]
> >>> So, yes, the mapping should be allowed to specified by the low-level
> >>> driver, but at the same time every vendor should not reinvent their own
> >>> enumeration method when we have EFI for that.
> >>
> >> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept
> >> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that
> >> TDX quotes are never TPM quotes, applications used to extend PCRs would
> >> have to be changed/recompiled. Then wouldn't it suffice to define the
> >> mappings as macros in an architecture specific header file?
> > 
> > I think something is wrong if applications are exposed to the PCR->RTMR
> > mapping thrash. I would hope / expect that detail is hidden behind a TPM
> > proxy layer sitting in front of this mapping on behalf of TPM-client
> > applications.
> 
> Hi Dan,
> 
> My apology for the confusion! I think we are talking about 2 different 
> scenarios - (1) this patch alone; and (2) this patch + vTPM.
> 
> Scenario 1: This patch provides RTMR access only. My assumption is, 
> there are existing application (and/or kernel modules) that extend to 
> PCRs today and would like to work in TDs where only RTMRs are available. 
> Changes are of course necessary in those applications as TPMs/PCRs are 
> no longer available, but from security perspective they would like to 
> keep the same activity log and just change to use RTMRs (in lieu of 
> PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and 
> must be agreed upon by all those applications and relying parties. IIUC, 
> this is the intention of having PCR->RTMR mapping config maintained by 
> the kernel, as proposed by Sam O. originally.
> 
> Scenario 2: A vTPM is implemented on top of this patch, in which case 
> the existing applications don't have to change as they can continue 
> extending to the same PCRs, which will then be emulated by the 
> underlying vTPM implementation. PCR->RTMR mapping in this scenario is 
> obviously internal to the vTPM and I agree with you completely that it 
> should be hidden inside the vTPM.
> 
> My comment in my previous email was regarding Scenario 1. I hope the 
> clarification above helps.

Got it, yes, makes sense.

I think the only use cases in scenario 1 are either kernel internal or
the backend of the vTPM implementation.

Even though RTMR is cross-platform it is not universal, so vTPM remains
the universal solution for most applications.
  

On 1/23/24 10:48 AM, Xing, Cedric wrote:
> On 1/22/2024 2:32 PM, Dan Williams wrote:
>> Xing, Cedric wrote:
>> [..]
>>>> So, yes, the mapping should be allowed to specified by the low-level
>>>> driver, but at the same time every vendor should not reinvent their own
>>>> enumeration method when we have EFI for that.
>>>
>>> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept
>>> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that
>>> TDX quotes are never TPM quotes, applications used to extend PCRs would
>>> have to be changed/recompiled. Then wouldn't it suffice to define the
>>> mappings as macros in an architecture specific header file?
>>
>> I think something is wrong if applications are exposed to the PCR->RTMR
>> mapping thrash. I would hope / expect that detail is hidden behind a TPM
>> proxy layer sitting in front of this mapping on behalf of TPM-client
>> applications.
>
> Hi Dan,
>
> My apology for the confusion! I think we are talking about 2 different scenarios - (1) this patch alone; and (2) this patch + vTPM.
>
> Scenario 1: This patch provides RTMR access only. My assumption is, there are existing application (and/or kernel modules) that extend to PCRs today and would like to work in TDs where only RTMRs are available. Changes are of course necessary in those applications as TPMs/PCRs are no longer available, but from security perspective they would like to keep the same activity log and just change to use RTMRs (in lieu of PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and must be agreed upon by all those applications and relying parties. IIUC, this is the intention of having PCR->RTMR mapping config maintained by the kernel, as proposed by Sam O. originally.
>
> Scenario 2: A vTPM is implemented on top of this patch, in which case the existing applications don't have to change as they can continue extending to the same PCRs, which will then be emulated by the underlying vTPM implementation. PCR->RTMR mapping in this scenario is obviously internal to the vTPM and I agree with you completely that it should be hidden inside the vTPM.
>
> My comment in my previous email was regarding Scenario 1. I hope the clarification above helps.


IMO, we should adapt an approach with as minimal user changes as possible. So I think we should try to avoid scenario 1 if possible.


>
> -Cedric
>