Received-SPF: pass (google.com: domain of linux-kernel+bounces-63945-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 13 Feb 2024 18:54:16 +0200
From: Mikko Ylinen <mikko.ylinen@linux.intel.com>
To: "Xing, Cedric" <cedric.xing@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>,
	Dan Middleton <dan.middleton@linux.intel.com>,
	Samuel Ortiz <sameo@rivosinc.com>, 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: <ZcueuCGgq-l9U4Er@himmelriiki>
References: <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>
 <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch>
 <226df539-b3f4-4099-b6a6-293fa200c536@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <226df539-b3f4-4099-b6a6-293fa200c536@intel.com>

On Mon, Feb 12, 2024 at 11:36:27PM -0800, Xing, Cedric wrote:
> On 2/9/2024 12:58 PM, Dan Williams wrote:
> > James Bottomley wrote:
> > > 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.
> > 
> I'm not a TCG expert. As far as I know, https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52_pub-1.pdf
> defines the event types for TCG2 logs for firmware uses only. I cannot find
> a spec that defines event types for OS or applications. We may reuse the
> firmware event types for Linux but I doubt they can accommodate IMA.
> 
> IMHO, we don't have to follow TCG2 format because TDX is never TPM, nor are
> any other TEEs that support runtime measurements. The existing TCG2 format
> looks to me somewhat like ASN.1 - well defined but schema is needed to
> decode. In contrast, JSON is a lot more popular than ASN.1 nowadays because
> it's human readable and doesn't require a schema. I just wonder if we should
> introduce a text based log format. We could make the log a text file, in
> which each line is an event record and the digest of the line is extended to
> the specified runtime measurement register. The content of each line could
> be free-form at the ABI level, but we can still recommend a convention for
> applications - e.g., the first word/column must be an URL for readers to
> find out the format/syntax of the rest of the line. Thoughts?

There's also the 'Canonical Event Log' format from TCG. It
covers IMA but it looks it's PC/client specific otherwise.

systemd seems to be following this format for its systemd-pcr*
services and exposing the log in JSON format under /run/log [1].

[1] https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrphase.service.html

> 
> > ...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.
> 
> We don't have to, and are also not supposed to I guess, append to the log
> generated by BIOS. The kernel can start a new log, and potentially in a
> different format. I think the BIOS log is exposed via securityfs today. Am I
> correct? For the new TEE measurement log, I don't think it has to be
> collocated with the BIOS log, because TEEs are never TPMs.

-- 
Regards, Mikko