Received-SPF: pass (google.com: domain of linux-kernel+bounces-32269-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs
From: Qinkun Bao <qinkun@google.com>
In-Reply-To: <Za1G9I+tYuIL9ser@vermeer>
Date: Sun, 21 Jan 2024 18:13:28 -0800
Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>,
 Dan Williams <dan.j.williams@intel.com>,
 linux-coco@lists.linux.dev,
 linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF3D8DE1-AD47-4A77-B8BD-8A12A6F7E9DB@google.com>
References: <20240114223532.290550-1-sameo@rivosinc.com>
 <20240114223532.290550-4-sameo@rivosinc.com>
 <1bbf8d3e-aa94-48c7-a1e4-76f9eefc4af7@linux.intel.com>
 <65a72c305291f_3b8e29484@dwillia2-xfh.jf.intel.com.notmuch>
 <5539c533-37b2-4b12-a5c5-056881cf8e3c@linux.intel.com>
 <Za1G9I+tYuIL9ser@vermeer>
To: Samuel Ortiz <sameo@rivosinc.com>,
 jiewen.yao@intel.com,
 ken.lu@intel.com


> On Jan 21, 2024, at 8:31=E2=80=AFAM, Samuel Ortiz <sameo@rivosinc.com> =
wrote:
>=20
> On Tue, Jan 16, 2024 at 07:35:30PM -0800, Kuppuswamy Sathyanarayanan =
wrote:
>>=20
>> 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.
>>>>>=20
>>>>> TPM PCR mappings are configured through configfs:
>>>>>=20
>>>>> // 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
>>>>>=20
>>>>> // Map RTMR 0 to PCRs 4, 5, 6, 7 and 8
>>>>> echo 4-8 > /sys/kernel/config/tsm/rtmrs/rtmr0/tcg_map
>>>>>=20
>>>>> // 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 ?
>>>>=20
>>>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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=20=

TDX RTMR and TPM PCRs (See =
https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trus=
t-domain-extension). The current RTMR implementation in the boot loader=20=

is =E2=80=9Chooked=E2=80=9D in the implementation for the TPM.=20

When the bootloader needs to extend the PCR value, it calls=20
`map_pcr_to_mr_index`  to retrieve the corresponding RTMR index and=20
then extends the RTMR. Considering this behavior, I don=E2=80=99t 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.

>=20
>> 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().
>=20
> Extend and read, yes.
>=20
>> 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.
>=20
> 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.
>=20
> Cheers,
> Samuel.
>=20
>=20