linux-kernel - Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 9 Feb 2024 12:58:09 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>, "Kuppuswamy
 Sathyanarayanan" <sathyanarayanan.kuppuswamy@...ux.intel.com>, "Xing, Cedric"
	<cedric.xing@...el.com>, Dan Williams <dan.j.williams@...el.com>, "Dan
 Middleton" <dan.middleton@...ux.intel.com>, Samuel Ortiz <sameo@...osinc.com>
CC: Qinkun Bao <qinkun@...gle.com>, "Yao, Jiewen" <jiewen.yao@...el.com>,
	Dionna Amalie Glaze <dionnaglaze@...gle.com>, <biao.lu@...el.com>,
	<linux-coco@...ts.linux.dev>, <linux-integrity@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI

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.