linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Samuel Ortiz <sameo@rivosinc.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: Qinkun Bao <qinkun@google.com>, "Lu, Ken" <ken.lu@intel.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs
Date: Mon, 22 Jan 2024 08:49:10 +0100	[thread overview]
Message-ID: <Za4d9iS/lpEOEzpl@vermeer> (raw)
In-Reply-To: <MW4PR11MB5872F46A2089C8C2D8EF7A008C752@MW4PR11MB5872.namprd11.prod.outlook.com>

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.

  reply	other threads:[~2024-01-22  7:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14 22:35 [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 1/4] tsm: Runtime measurement register support Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs Samuel Ortiz
2024-01-16 22:28   ` Kuppuswamy Sathyanarayanan
2024-01-17  1:24     ` Dan Williams
2024-01-17  3:35       ` Kuppuswamy Sathyanarayanan
2024-01-21 16:31         ` Samuel Ortiz
2024-01-22  2:13           ` Qinkun Bao
2024-01-22  2:23             ` Yao, Jiewen
2024-01-22  7:49               ` Samuel Ortiz [this message]
2024-01-22 20:10               ` Dan Williams
2024-01-22 21:58                 ` Xing, Cedric
2024-01-22 22:32                   ` Dan Williams
2024-01-23 18:48                     ` Xing, Cedric
2024-01-23 19:14                       ` Dan Williams
2024-01-23 20:59                       ` Kuppuswamy Sathyanarayanan
2024-01-26 16:55                         ` Dionna Amalie Glaze
2024-01-23  1:22                   ` Yao, Jiewen
     [not found]           ` <90EDEF2B-DB43-413F-840E-3268977FDBD0@google.com>
2024-01-22  7:46             ` Samuel Ortiz
2024-01-22 15:04               ` Kuppuswamy Sathyanarayanan
2024-01-22 22:12           ` Kuppuswamy Sathyanarayanan
2024-01-14 22:35 ` [RFC PATCH v1 4/4] tsm: Allow for extending and reading configured RTMRs Samuel Ortiz
2024-01-16 20:44 ` [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI Dan Williams
2024-01-18  3:35 ` biao.lu
2024-01-18 17:42   ` Dionna Amalie Glaze
2024-01-18 19:20     ` Dan Williams
2024-01-21 18:11   ` Samuel Ortiz
2024-01-21 19:15     ` Dan Williams
2024-01-22 22:12       ` Xing, Cedric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Za4d9iS/lpEOEzpl@vermeer \
    --to=sameo@rivosinc.com \
    --cc=dan.j.williams@intel.com \
    --cc=jiewen.yao@intel.com \
    --cc=ken.lu@intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qinkun@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).