From: Lukas Wunner <lukas@wunner.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: 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>, 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,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
Date: Thu, 22 Feb 2024 16:45:29 +0100 [thread overview]
Message-ID: <20240222154529.GA9465@wunner.de> (raw)
In-Reply-To: <332775d7218843d6cc168c963d76e6841eab5d5b.camel@HansenPartnership.com>
Hi James,
On Wed, Feb 07, 2024 at 04:46:36PM -0500, 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.
At last year's Plumbers BoF on PCI device authentication & encryption,
you requested that the kernel exposes proof of SPDM signature validation
so that user space can verify after the fact that the kernel did
everything correctly.
Your above comment seems to indicate that you prefer TCG2 CEL as the
format to expose the information, however the format seems ill-suited
for the purpose:
Per TCG PFP v1.06r52 sec 3.3.7, an SPDM CHALLENGE event merely logs
the nonce used. That's not sufficient to verify the signature:
The signature is computed over a hash of the concatenation of all
the messages exchanged with the device:
* GET_VERSION request + VERSION response
* GET_CAPABILITIES request + CAPABILITIES response
* NEGOTIATE_ALGORITHMS request + ALGORITHMS response
* GET_DIGESTS request + DIGESTS response
* GET_CERTIFICATE request + CERTIFICATE response (can be multiple)
* CHALLENGE request + CHALLENGE_AUTH response
The content of those SPDM messages is not necessarily static:
E.g. the SPDM requester (the kernel) presents all supported algorithms
and the SPDM responder (the device) selects one of them.
If only the nonce is saved in the log, the verifier in user space would
need to know exactly which algorithms were supported by the SPDM requester
at the time the request was sent (could since have changed through a
kernel update). It also needs to know exactly which algorithm the
SPDM responder picked.
Armed with the knowledge which algorithm bits were set, the verifier
would have to reconstruct the messages that were exchanged between
SPDM requester and responder so that it can calculate the hash over
their concatenation and verify the signature.
The algorithm selection is but one example of bits that can vary between
different requesters/responders and between different points in time.
The SPDM protocol allows a great deal of flexibility/agility here.
The nonces sent by requester and responder are not the only bits that are
variable, is what I'm trying to say. Storing the nonces in the log is
sufficient to prove their freshness, but it is not sufficient to prove
correct validation of the signature.
I'd have to store the full concatenation of all exchanged SPDM messages
in the log to facilitate that. Personally I have no problem doing so,
but it won't be possible with the CEL format as currently specified by TCG.
So on the one hand I'd like to fulfil your Plumbers request to expose
proof of correct signature validation and on the other hand you're
requesting CEL format which is insufficient to fulfil the request.
I don't really know how to reconcile that.
I do see value in exposing the full concatenation of all exchanged
SPDM messages: It would allow piping that into wireshark or tshark
to decode the messages into human-readable form, which might be useful
for debugging SPDM communication with the device.
In fact, an SPDM dissector for wireshark already exists, though it's
not up-to-date (last change 3 years ago) and probably needs a cleanup
before it can be upstreamed: https://github.com/jyao1/wireshark-spdm/
I'm considering adding a custom sysfs interface which exposes the last,
say, 64 SPDM events of each device, comprising:
* type of event (CHALLENGE or GET_MEASUREMENTS)
* timestamp
* all exchanged messages
* hash of all exchanged messages
* hash algorithm used
* signature received from device
* certificate chain used for signature validation
The memory consumption for all that data would be significant and the
format wouldn't be TCG2 CEL, but it would fulfil your request to provide
proof of signature verification.
Thoughts?
Thanks,
Lukas
prev parent reply other threads:[~2024-02-22 15:54 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
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 [this message]
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=20240222154529.GA9465@wunner.de \
--to=lukas@wunner.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Jonathan.Cameron@huawei.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.