Received-SPF: pass (google.com: domain of linux-kernel+bounces-28424-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 16 Jan 2024 17:24:00 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>,
	Samuel Ortiz <sameo@rivosinc.com>, Dan Williams <dan.j.williams@intel.com>
CC: <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
Message-ID: <65a72c305291f_3b8e29484@dwillia2-xfh.jf.intel.com.notmuch>
References: <20240114223532.290550-1-sameo@rivosinc.com>
 <20240114223532.290550-4-sameo@rivosinc.com>
 <1bbf8d3e-aa94-48c7-a1e4-76f9eefc4af7@linux.intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1bbf8d3e-aa94-48c7-a1e4-76f9eefc4af7@linux.intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CIlLovDqBWKHnQFIotRDtnsV9whRjyjL+DgjR/4QJoYUwXRqq+HqfaUlJtw0?=
 =?us-ascii?Q?ExN599ew6RxCvGl7edLxXjbGyUeRhbmJ2QJBSHi63W0n9En31BRF2W45wqoR?=
 =?us-ascii?Q?FT/NJWRUmQSf3ETzOGr77LaLOWkMldoPoLP11bbx0OWfUix169B6t5rhuNWW?=
 =?us-ascii?Q?k8XxVzqlBdCdG7E+t7k22bukAbkIQ651p9lZDZr1sOV/65SekyQeETjSoCRh?=
 =?us-ascii?Q?0rXWlERMEjtTbnCkk3AhUVmvUdZJ7/uf1JSQAXUdqxULZ+VrDkpi8wAb0WyF?=
 =?us-ascii?Q?ihPwoWZfN1Xn4DjAyJ6aqEXBSGGBS1FEOKqA+FUwWGlhITg0cCtzT7AsFvDj?=
 =?us-ascii?Q?3OVdvM1fv2htWNTO+7Dwk1nx0HTFX3nNHe5Pf1JXyLlN6pJi0n3pzJO4Cw4i?=
 =?us-ascii?Q?58E3mlVTbXVC09pXch/fXiY5lMlpwsTBYlwg6JtbYAW9KuR3CDzVUTkpgMDC?=
 =?us-ascii?Q?VV4DIK8K2HjYBDwq2oywbrgDkJ6Az1yTxw4S8It2GkSkV9+6vINHtEZGmA03?=
 =?us-ascii?Q?9U82X3NDCr5mphi13Ah4phz9dzo1BJsYhHipmyHloKmqAHA7GdosI/uHS9HY?=
 =?us-ascii?Q?0P77B+MpZtgixqyo4fydBWkq8UynisczcSdavAYmRUHPACI8zpv8ALSOIKD7?=
 =?us-ascii?Q?tQtL+64j9y4fo6C9ZSkqhqHjwLVJ00rkgpWHdLa3E+nkaAkfnYLS8d4SqL1J?=
 =?us-ascii?Q?Geb50iPGqlU1RMI2ZDMtLltMh52v1RkYOWDZWslCXFuG/i6vr/DRuux3XTSc?=
 =?us-ascii?Q?OL9sI8/yeIoZmKH91nz5Ex3Y/fR4aERwC69BmtY4q3LjqQd0EtCbEX6HSiBn?=
 =?us-ascii?Q?+a572oiG35g5hJo0lTJ4tAUcL3o55ZcBgC0YaCRJGD8LmCwfqxUZ3Z8483WX?=
 =?us-ascii?Q?/y1XsJUEXLWkPBiwtn2i/U+f08pV4qy5wqbTGdldTj/MCDVaMHNSCXb7Savf?=
 =?us-ascii?Q?FE6ZX0RwVZcBvHgQWgLo8eVP4So2++iK8bLRjTXNcSpKJkOvVAqq3sxHDWQn?=
 =?us-ascii?Q?RF/oeIRT6n977Wm5/YeDC8POWS54DuCpYRroT2HxBnm9eyW5I2QEcYS94Z9T?=
 =?us-ascii?Q?+uY1FKQDJTnAku60cc/8IDBbD1R8V/yyrU6mf6z8t+HVfSoxCYm/ndoptGwW?=
 =?us-ascii?Q?UFgQP3B9i8UwgACUOQr35kzXzTNCjQJoMQZO4U0q9adtgNcz0PTEFVV5qLCN?=
 =?us-ascii?Q?TMep4W39UD52SyWh4pmNZr2s8GIsU8gTxehQvu+lFrmM1rna8Uk0pWRANYmk?=
 =?us-ascii?Q?UDo8Iub2e845Rd5xS3VwjUvEBR3wv3YxLgsyeQ1+iugVpjtvNaX58POldOKK?=
 =?us-ascii?Q?pYP8zUY7/s/0S3hNykompNPNDusBEKDEQPO3egVi3M7ZYxU9ejbcvQo1JX0z?=
 =?us-ascii?Q?qb1/FwQvGaaQrqoCzVLgxmIhJmXXqvFBJ+c8EqxoDd/wtdGMj1zem/Z+OU2P?=
 =?us-ascii?Q?m7o43SlL8Z6C9NGYdfTn0bRdwipmegRW0xhOwE7kWaxfQf5mKR6ugFfyJ/05?=
 =?us-ascii?Q?6ZN1aGIHBAR7ZKEYHbnE0MrEY1IR9urUKaRouCvqO6XvnGClbjcTMLmzkXrU?=
 =?us-ascii?Q?Qha3sVU+uzNPdS3hechV7jKyAGk2rZYwj/GO9BumdbhartmUQi0kHXBoBP+w?=
 =?us-ascii?Q?AA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e9fc680c-6cb0-44d9-7bb0-08dc16fafd2d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2024 01:24:02.6247
 (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: chdyRUKkzp/6YwnnWZmQW/LAHsjrIM/QZkf/9pyqiH0/JGWzLDexzfB2btq9DRI5rTqlxrpzb43QiuTOy3o2C1yGsymH1Q1fgvDu4Jjph2Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6120
X-OriginatorOrg: intel.com

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.