Received-SPF: pass (google.com: domain of linux-kernel+bounces-57239-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.com>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: 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
Date: Wed, 07 Feb 2024 16:46:36 -0500
In-Reply-To: <527da630-4952-4b1d-80c0-5a87997ff9fd@linux.intel.com>
References: <20240128212532.2754325-1-sameo@rivosinc.com>
	 <c17a31e4fb30f5f9d4a337e5bd8d54cc6f99eef7.camel@HansenPartnership.com>
	 <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>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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.

> 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?). 

James