From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Xing, Cedric" <cedric.xing@intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Dan Middleton <dan.middleton@linux.intel.com>,
Samuel Ortiz <sameo@rivosinc.com>,
Dan Williams <dan.j.williams@intel.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: Tue, 06 Feb 2024 08:57:45 +0000 [thread overview]
Message-ID: <fe1722c3618a8216cb53b8fd3f1b7cbb6fdff5a0.camel@HansenPartnership.com> (raw)
In-Reply-To: <b8140cc8-a56b-40f6-a593-7be49db14c77@intel.com>
On Tue, 2024-02-06 at 00:34 -0800, Xing, Cedric wrote:
[...]
> I'm not familiar with existing TPM code. Per
> https://elixir.free-electrons.com/linux/latest/source/drivers/char/tpm/tpm-interface.c#L314
> ,
> tpm_pcr_extend() doesn't seem to take/log the actual event, but only
> extends the PCR.
That's the low level code we build on. The TPM doesn't maintain a log
at all, just the measuring entity.
> IMA seems to maintain the measurement list/log by itself.
It does, yes.
> Am I right? If so, why do we want logging to be part of TSM
> here?
Well, as I said above: without a log you have a combinatoric explosion
of events that lead to the PCR value.
> For measured boots, I think UEFI BIOS has already maintained a log so
> what's needed here is just to expose the log somewhere in sysfs.
> IMHO, I don't think logging is even necessary because everything in
> the boot flow is static, hence a relying party can simply compare
> measurement registers against known good values without looking at
> any log. But please correct me if I have missed anything.
Without the log the UEFI boot flow is way too brittle because
measurements aren't actually static and without knowing what happened
you can't reproduce the PCR value. It was actually the earliest
insight from the keylime project that it couldn't just define state by
PCR values and had to parse the log instead.
> > If you have a kernel backed log, the ABI for extending it should be
> > where you get the PCR extensions from, that way nothing can go
> > wrong. An API to extend the PCRs separately will only cause pain
> > for people who get it wrong (and lead to ordering issues if more
> > than one thing wants to add to the log, which they will do because
> > neither the TPM nor the RTMRs have enough registers to do one per
> > process that wants to use it if this becomes popular).
> >
> There's an easy way to solve the synchronization problem in user mode
> by applying flock() on the log file - i.e., a process can extend a
> measurement register only when holding an exclusive lock on the
> corresponding log file.
Which would be where exactly? and owned by whom?
> A possible drawback is it'd allow a malicious
> process to starve all other processes by holding the lock forever, or
> to mess up the log file content intentionally. But that shouldn't be
> a practical problem because the existence of such malicious processes
> would have rendered the CVM untrustworthy anyway - i.e., should the
> CVM still be able to generate a valid attestation, that would only
> lead to a distrust decision by any sane relying party.
>
> IMHO, if something can be easily solved in user mode, probably it
> shouldn't be solved in kernel mode.
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.
James
next prev parent reply other threads:[~2024-02-06 8:57 UTC|newest]
Thread overview: 35+ 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-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 [this message]
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
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
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=fe1722c3618a8216cb53b8fd3f1b7cbb6fdff5a0.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=biao.lu@intel.com \
--cc=cedric.xing@intel.com \
--cc=dan.j.williams@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.