linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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.

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