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
Date: Fri, 9 Feb 2024 12:58:09 -0800 [thread overview]
Message-ID: <65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.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.
next prev parent reply other threads:[~2024-02-09 20:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-28 21:25 [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI Samuel Ortiz
2024-01-28 21:25 ` [RFC PATCH v2 1/4] tsm: Runtime measurement register support Samuel Ortiz
2024-01-29 16:57 ` Dionna Amalie Glaze
2024-02-01 22:03 ` Jarkko Sakkinen
2024-01-28 21:25 ` [RFC PATCH v2 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy Samuel Ortiz
2024-01-28 22:38 ` Kuppuswamy Sathyanarayanan
2024-02-01 22:05 ` Jarkko Sakkinen
2024-02-21 16:16 ` Mikko Ylinen
2024-01-28 21:25 ` [RFC PATCH v2 3/4] tsm: Map RTMRs to TCG TPM PCRs Samuel Ortiz
2024-01-28 22:44 ` Kuppuswamy Sathyanarayanan
2024-02-02 6:18 ` James Bottomley
2024-01-28 21:25 ` [RFC PATCH v2 4/4] tsm: Allow for extending and reading configured RTMRs Samuel Ortiz
2024-05-11 2:57 ` James Bottomley
2024-05-13 10:16 ` Samuel Ortiz
2024-05-13 14:03 ` James Bottomley
2024-05-14 5:08 ` Samuel Ortiz
2024-05-16 8:33 ` Xing, Cedric
2024-02-01 22:02 ` [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI Jarkko Sakkinen
2024-02-02 6:24 ` James Bottomley
2024-02-02 23:07 ` Dan Middleton
2024-02-03 6:03 ` James Bottomley
2024-02-03 7:13 ` Kuppuswamy Sathyanarayanan
2024-02-03 10:27 ` James Bottomley
2024-02-06 8:34 ` Xing, Cedric
2024-02-06 8:57 ` James Bottomley
2024-02-07 2:02 ` Dan Williams
2024-02-07 20:16 ` Xing, Cedric
2024-02-07 21:08 ` Kuppuswamy Sathyanarayanan
2024-02-07 21:46 ` James Bottomley
2024-02-09 20:58 ` Dan Williams [this message]
2024-02-13 7:36 ` Xing, Cedric
2024-02-13 16:05 ` James Bottomley
2024-02-14 8:54 ` Xing, Cedric
2024-02-15 6:14 ` Dan Williams
2024-02-16 2:05 ` Xing, Cedric
2024-03-05 1:19 ` Xing, Cedric
2024-04-17 20:23 ` Dan Middleton
2024-02-13 16:54 ` Mikko Ylinen
2024-02-15 22:44 ` Dr. Greg
2024-02-22 15:45 ` Lukas Wunner
2024-08-19 21:25 ` Qinkun Bao
2024-08-20 13:19 ` Samuel Ortiz
2024-08-20 19:44 ` Qinkun Bao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65c691e13a50d_afa42948a@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=biao.lu@intel.com \
--cc=cedric.xing@intel.com \
--cc=dan.middleton@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=jiewen.yao@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qinkun@google.com \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).