Received-SPF: pass (google.com: domain of linux-kernel+bounces-35974-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Tue, 23 Jan 2024 11:14:26 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: "Xing, Cedric" <cedric.xing@intel.com>, Dan Williams
	<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-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
Message-ID: <65b010121635d_37ad294f3@dwillia2-xfh.jf.intel.com.notmuch>
References: <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>
 <CF3D8DE1-AD47-4A77-B8BD-8A12A6F7E9DB@google.com>
 <MW4PR11MB5872F46A2089C8C2D8EF7A008C752@MW4PR11MB5872.namprd11.prod.outlook.com>
 <65aecbbce09dd_107423294b7@dwillia2-xfh.jf.intel.com.notmuch>
 <c3b99264-233b-4997-9e20-c4c2693b8cdc@intel.com>
 <65aeecea827f0_37ad2948@dwillia2-xfh.jf.intel.com.notmuch>
 <14dffda2-f413-4304-9932-3ac8ddfb30e4@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <14dffda2-f413-4304-9932-3ac8ddfb30e4@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?nE5xIiW1lfwLYmGVBfpAJ6P8dLbRxeX059O6I+c6DVQSvoQXwtuPacpkL6CG?=
 =?us-ascii?Q?l3EC/jUkRm9Fgex2iu9tw7ysJmVuuZZfCdMqe6J3Uz06E/g5sLbRTYFBhSzW?=
 =?us-ascii?Q?2CWjhN4dbjiDuEvzrqix6OQvxu27oNpdvVHTRiakmQd+ihLJBAEoTp86rVVc?=
 =?us-ascii?Q?8B0BkZ2BtlvHNxOUQPlE4nXEzO9EYUPMqg0GrhRDqdUNpifeGb7mQbT+939X?=
 =?us-ascii?Q?KKRZAxTvIbaA0iriqEexM7TtNaBTM0WIcVyXyBTiYmKuDoZkjRtNB3ANAPR1?=
 =?us-ascii?Q?S44EsoaNy+YYasGAqyn8HL33HTnEd0EbdpGBK9cHkguwWRq9ITJHquUyVHQ5?=
 =?us-ascii?Q?L8E/AWQ3Ye0Ukn53AVqNno0cjxRpVTkCKqJGjiBB2Icdnky/zTUIe+kgnzv2?=
 =?us-ascii?Q?tW8X+0RBmxy53qEUq/0IkDva6Xl7AUPgouw3gUe5sIY751QChQPuWyQUIDRV?=
 =?us-ascii?Q?HDoXfrMAVeAcQV8IUUOIw5h7QjGJI/zTvmZzfqNjN3puszeqzxVEq4RcSm+W?=
 =?us-ascii?Q?Cm9klBGV9SAFWjv8yhRrpoRjSAY6AJcXaw/XcWPS6Hu+RWujSftoxOEn4L7y?=
 =?us-ascii?Q?6IRfvftOTOzlKqX6D2ihpS5YHO6TE5wCF3599NfWIGR6V+BMgRik5/2y8XC2?=
 =?us-ascii?Q?k3f54951xAI4OZt7t8h967UJky2uJtxFXnIWU/EdZxaQ9aCa4f29hBdgr+Qg?=
 =?us-ascii?Q?F9lOdvk93XmDofnFFMOL/EDvFsNVjPo5xocYdzu/WvKqd90LEVgjUVVi0PTq?=
 =?us-ascii?Q?I7+0ZfLkhhBs7f9qCQUfGNp/lVrxB57H0tCzFNYefxc7Al9JY8UGqv8R2CZO?=
 =?us-ascii?Q?MkT+TsbXk4Jv/0ih0bdIbm5xYFospqAMAIlma5RpSir203hSEMJIkTuGwwk2?=
 =?us-ascii?Q?MMJeGSS6DRnwhou9sm3AbgCA+UPTZ6gj3F6lBuy4oPOUwEv/jZbOf0c+Gq27?=
 =?us-ascii?Q?fGu6QRDrM2dYsPWH4J11Fpd4WLxyYu5vESljfDgvnnBkZqTgeVF+rGyipNpZ?=
 =?us-ascii?Q?SRZGxxGiv7YnbYRloGIVtDi9MGGGZJzfQegDjrUTemowViz2A17LafkOCp77?=
 =?us-ascii?Q?FclG5D/krzSag4yhF6Sktjtb0zAVxsjCyHVGHXCfVdKkg35cyMWjy4Gw3Sn0?=
 =?us-ascii?Q?qbRJFtp94aVTel5/ZuOQpocRzDm/FS89GfI1Ov4uO4rwutRk50Ske7dK+iYU?=
 =?us-ascii?Q?EROEpimjwIumtfaVd6ufuwVGl6ELxxDaAuig8Kyq2wVVRSSLJlscfMPSI8ZS?=
 =?us-ascii?Q?Iw9X1afLYAjXmjVqmGtYQBtO5+Y3/A1u92vY+yHAdtGewDWA+L5M/RTyGoG5?=
 =?us-ascii?Q?gs3cRPS3qlnZ0aXYP2LizVyCvtW9/Hlff3PgZQuX/69sdVEWQIBTCHjuQtYO?=
 =?us-ascii?Q?PENkS3109WSRbvoTdBlA+g2Us81EUibjgrc5CrZg1hV3SgI2ZoeW92WL6vKT?=
 =?us-ascii?Q?SMAnuLzvHkDLPlXGBVKxuYr1bq33BQffonJgquqf2NChEzXXpGy64sEJNQxT?=
 =?us-ascii?Q?a9lvGRz2rSu4XRmCH5UzvOukKvTY4/SZNzNOXzNpDbGQZ59vOZHQxHDMNcbM?=
 =?us-ascii?Q?DvZG/WI8Ywm4UKFmi75AmKWX9hCI55yyHX7RBISGNJTN9kfTm7QUuxaMsRAi?=
 =?us-ascii?Q?9w=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 38671d10-3f8b-45ca-a763-08dc1c478543
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2024 19:14:28.5211
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8m7k+neYmWh4M9d7YTDatSvUy7yVh1mOETtKo8UN5llE5nWoyhwiOrFZCyYniAUvZ605qTZcEYNs3eUlT+fuVSwYga+2bHFXUCAebot6Or0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6060
X-OriginatorOrg: intel.com

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.