Received-SPF: pass (google.com: domain of linux-kernel+bounces-59972-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Fri, 9 Feb 2024 12:58:09 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>, "Kuppuswamy
 Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>, "Xing, Cedric"
	<cedric.xing@intel.com>, Dan Williams <dan.j.williams@intel.com>, "Dan
 Middleton" <dan.middleton@linux.intel.com>, Samuel Ortiz <sameo@rivosinc.com>
CC: Qinkun Bao <qinkun@google.com>, "Yao, Jiewen" <jiewen.yao@intel.com>,
	Dionna Amalie Glaze <dionnaglaze@google.com>, <biao.lu@intel.com>,
	<linux-coco@lists.linux.dev>, <linux-integrity@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
Message-ID: <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch>
References: <a255bc36-2438-41b7-b304-bcf7a6628bef@linux.intel.com>
 <42e14f74d3819c95fdb97cd2e9b2829dcb1b1563.camel@HansenPartnership.com>
 <1557f98a-3d52-4a02-992b-4401c7c85dd7@linux.intel.com>
 <85b7a4a679eada1d17b311bf004c2d9e18ab5cd3.camel@HansenPartnership.com>
 <b8140cc8-a56b-40f6-a593-7be49db14c77@intel.com>
 <fe1722c3618a8216cb53b8fd3f1b7cbb6fdff5a0.camel@HansenPartnership.com>
 <65c2e4aa54a0_d4122947f@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <22088ed3-51a4-415f-932c-db84c92a2812@intel.com>
 <527da630-4952-4b1d-80c0-5a87997ff9fd@linux.intel.com>
 <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?9Afovn+I3jsRmE6YpiBe60UZVqAKeITviKerVasj1unBkfu4hYPKnayAry?=
 =?iso-8859-1?Q?pj1NU4zvbGcQMbCPUepd6Z9YlpjPR6O0Zs8l8lAJYYlV43RIL31PbT6Aup?=
 =?iso-8859-1?Q?fnRRkQ1kpbUunNA/visb86H1I5UGkDCM1HHJ0neB7KFeKSA6n1jUs9x1cw?=
 =?iso-8859-1?Q?jxQvtfUJ/CeCl5Gv5MGgdhzeywj206Tts2JBQmXpq9jHn+S0IHkm6y4iE+?=
 =?iso-8859-1?Q?g4r9jMG3bKrtDu0EOl1hzFu+YZ+H1l9zULtQqhhyajxIrD3WKebp38Wkoo?=
 =?iso-8859-1?Q?XlPUkonntwNaeWQ/rgJH4XSx2D4eBeFJKnB38nwwy6rosVUpai98K8h59o?=
 =?iso-8859-1?Q?wBxQlJoAbJSUMI/UQTyP+pL3ELR+t+Q31jEE7zrV4i7tk7otdYuWHSSewR?=
 =?iso-8859-1?Q?n4p2iN/73Re6jI14vOt42G4xPvTxydM5eHqUXG0AshLm75cGZh8kkUGLEO?=
 =?iso-8859-1?Q?9xAcqONwa1K6hFKjyOT+OX29Vo5n3J870EWqcInqOI2ParK2UgEeosHMCa?=
 =?iso-8859-1?Q?qNDSM31Yxj5Cm/I7O7d3yOy61y18Xu7uogPh3PYKrvXjxSklhBXP8myD6l?=
 =?iso-8859-1?Q?/ZzKAlAI2cktNzLOBXBC9c3AT1XwW+SHxeUQHHW7PAkSme+jQGkJkbvRbr?=
 =?iso-8859-1?Q?3f7mZdPnz8Ss6RcLKjtP/Rgq37Dj/KnIM6IulkNoBuypi7DK29nPxjtmls?=
 =?iso-8859-1?Q?f2ke5ix3JRSdfnKjH+bytPIk+hR4uk2Z9DqNdbzalS1dipobb/R72q++M6?=
 =?iso-8859-1?Q?snL0tJgF8VWTVFWvUVvzNMSJZkbaZ6l5EKDr8nrBo0EFqDcAxIAD+a9ZXR?=
 =?iso-8859-1?Q?DAXDAJ88yqDf4fRqqjxr06vkOwEXUdo25j8MHXwWd7u5CdmGpCglh1kMY6?=
 =?iso-8859-1?Q?k/uk62z8whQKA/lvG3Qa/uRl5oEoDAdaL2rVvlJX1cN/UfIWjOXUZuVLiz?=
 =?iso-8859-1?Q?5/qlWu7BDs/HM/nEEICSR5h0kMXJEn7WdMN7UqfbFSrdFMswxyPevNoiiW?=
 =?iso-8859-1?Q?cj6KRXIcOKVbnM+xJg9q61SCEQobng8RR0DzGhDZixpxRh1g5MJyBRti8W?=
 =?iso-8859-1?Q?DXt1ehkb3d7Gc17bxTSoKSh9Wf0VxqLL8gmX+9aDw3u3oMSPCIRLkBDUwZ?=
 =?iso-8859-1?Q?yVEh0LEjDRR/q5o3ApA8/7ykQsA/7DXhkyVmWtGhJfd/s2EjNn3CbgS4ym?=
 =?iso-8859-1?Q?D6B3jKb8sfGzJCEhgUsU+HZU8JHeZ5DqAifa3BzhJsT7wArX7g81IsF/LC?=
 =?iso-8859-1?Q?I5URyL1jIyeVO2GQ2brkuociDmi9nfbhQCz7Vg/7ldDzuGO+GnmWH/w7m/?=
 =?iso-8859-1?Q?ovH1+3bMXCFWI2uRyLX9iV7NJJIorYLbSRRPlx31dtDaifytcjrGiEt9BP?=
 =?iso-8859-1?Q?mzkQghftp3w39aWIOgHonqjLzT00n1QaoniEhf5StSLyRSgNgJ7YUVmN0w?=
 =?iso-8859-1?Q?lT4NqHXD3vMamjpx2ZLnQQ5fsoT8FNrKUcwZZ1e0VUUJvDzWfEBmiNiAgH?=
 =?iso-8859-1?Q?5zzLdintf0a1urIUSOw+sNMX15yyDZJFOIklGxTeHHiK3yZeTSHl5dlZ7G?=
 =?iso-8859-1?Q?yAE5pjjq53Sa6wKgrrQvFbj0SbjstmgniMQnSaBYXFxTsQKcgJ58a8wfdP?=
 =?iso-8859-1?Q?P+g2/dAi5V85vrwjB41M0+dcBUhKWqZsNL/L23siGH/phcjV7892iC1A?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 790fc770-f369-4921-9eba-08dc29b1d3a0
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2024 20:58:11.7714
 (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: gU07aZeq4u7amzvbAJZlBduNZR0d7nQJUJs//Y6WW3ouUCD4H91VGKvKsbNuX0BfPQCLGHeuU/EvCZwFAJJyq3fv+VWWes8ix0MeV1A8Q/4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8428
X-OriginatorOrg: intel.com

James Bottomley wrote:
> On Wed, 2024-02-07 at 13:08 -0800, Kuppuswamy Sathyanarayanan wrote:
> > 
> > On 2/7/24 12:16 PM, Xing, Cedric wrote:
> > > On 2/6/2024 6:02 PM, Dan Williams wrote:
> > > > James Bottomley wrote:
> > > > > There isn't really anything more complex about an interface
> > > > > that takes a log entry, and does the record an extend, than an
> > > > > interface which takes a PCR extension value.? So best practice
> > > > > would say that you should create the ABI that you can't get
> > > > > wrong (log and record) rather than creating one that causes
> > > > > additional problems for userspace.
> > > > 
> > > > Agree, there's no need for the kernel to leave deliberately
> > > > pointy edges for userspace to trip over.
> > > > 
> > > > Cedric, almost every time we, kernel community, build an
> > > > interface where userspace says "trust us, we know what we are
> > > > doing" it inevitably results later in "whoops, turns out it would
> > > > have helped if the kernel enforced structure here". So the log
> > > > ABI adds that structure for the primary use cases.
> > > 
> > > Dan, I agree with your statement generally. But with the precedent
> > > of TPM module not maintaining a log, I just wonder if the addition
> > > of log would cause problems or force more changes to existing
> > > usages than necessary. For example, IMA has its own log and if
> > > changed to use RTMR, how would those 2 logs interoperate? We would
> > > also need to decide on a log format that can accommodate all
> > > applications.
> > 
> > 
> > IIUC, CC event logging in firmware uses TCG2 format. Since IMA
> > internally uses TPM calls, I assume it also uses the TCG2 format. I
> > think we can follow the same format for RTMR extension.
> 
> Just to correct this: IMA uses its own log format, but I think this was
> a mistake long ago and the new log should use TCG2 format so all the
> tools know how to parse it.

Is this a chance to nudge IMA towards a standard log format? In other
words, one of the goals alongside userspace consumers of the RTMR log
would be for IMA to support it as well as an alternate in-kernel backend
next to TPM. IMA-over-TPM continues with its current format,
IMA-over-RTMR internally unifies with the log format that is shared with
RTMR-user-ABI.

..but be warned the above is a comment from someone who knows nothing
about IMA internals, just reacting to the comment.


> > I am wondering where will the event log be stored? Is it in the
> > log_area region of CCEL table?
> 
> IMA stores its log in kernel memory and makes it visible in securityfs
> (in the smae place as the measured boot log).  Since this interface is
> using configfs, that's where I'd make the log visible.
> 
> Just to add a note about how UEFI works: the measured boot log is
> effectively copied into kernel memory because the UEFI memory it once
> occupied is freed after exit boot services, so no UEFI interface will
> suffice for the log location.
> 
> I'd make the file exporting it root owned but probably readable by only
> the people who can also extend it (presumably enforced by group?). 

I assume EFI copying into kernel memory is ok because that log has a
limited number of entries. If this RTMR log gets large I assume it needs
some way cull entries that have been moved to storage. Maybe this is a
problem IMA has already solved.