From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
David Howells <dhowells@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
David Woodhouse <dwmw2@infradead.org>,
"James Bottomley" <James.Bottomley@HansenPartnership.com>,
<linux-pci@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
<linux-coco@lists.linux.dev>, <keyrings@vger.kernel.org>,
<linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
David Box <david.e.box@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"Li, Ming" <ming4.li@intel.com>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Alistair Francis <alistair.francis@wdc.com>,
Wilfred Mallawa <wilfred.mallawa@wdc.com>,
Damien Le Moal <dlemoal@kernel.org>,
"Alexey Kardashevskiy" <aik@amd.com>,
Dhaval Giani <dhaval.giani@amd.com>,
Gobikrishna Dhanuskodi <gdhanuskodi@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>, Peter Gonda <pgonda@google.com>,
Jerome Glisse <jglisse@google.com>,
Sean Christopherson <seanjc@google.com>,
"Alexander Graf" <graf@amazon.com>,
Samuel Ortiz <sameo@rivosinc.com>,
Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Alan Stern" <stern@rowland.harvard.edu>
Subject: Re: [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs
Date: Thu, 18 Jul 2024 16:56:27 +0100 [thread overview]
Message-ID: <20240718165627.000052bc@Huawei.com> (raw)
In-Reply-To: <77f549685f994981c010aebb1e9057aa3555b18a.1719771133.git.lukas@wunner.de>
On Sun, 30 Jun 2024 21:50:00 +0200
Lukas Wunner <lukas@wunner.de> wrote:
> When authenticating a device with CMA-SPDM, the kernel verifies the
> challenge-response received from the device, but otherwise keeps it to
> itself.
>
> James Bottomley contends that's not good enough because user space or a
> remote attestation service may want to re-verify the challenge-response:
> Either because it mistrusts the kernel or because the kernel is unaware
> of policy constraints that user space or the remote attestation service
> want to apply.
>
> Facilitate such use cases by exposing a log in sysfs which consists of
> several files for each challenge-response event. The files are prefixed
> with a monotonically increasing number, starting at 0:
>
> /sys/devices/.../signatures/0_signature
> /sys/devices/.../signatures/0_transcript
> /sys/devices/.../signatures/0_requester_nonce
> /sys/devices/.../signatures/0_responder_nonce
> /sys/devices/.../signatures/0_hash_algorithm
> /sys/devices/.../signatures/0_combined_spdm_prefix
> /sys/devices/.../signatures/0_certificate_chain
> /sys/devices/.../signatures/0_type
>
> The 0_signature is computed over the 0_transcript (a concatenation of
> all SPDM messages exchanged with the device).
>
> To verify the signature, 0_transcript is hashed with 0_hash_algorithm
> (e.g. "sha384") and prefixed by 0_combined_spdm_prefix.
>
> The public key to verify the signature against is the leaf certificate
> contained in 0_certificate_chain.
>
> The nonces chosen by requester and responder are exposed as separate
> attributes to ease verification of their freshness. They're already
> contained in the transcript but their offsets within the transcript are
> variable, so user space would otherwise have to parse the SPDM messages
> in the transcript to find the nonces.
>
> The type attribute contains the event type: Currently it is always
> "responder-challenge_auth signing". In the future it may also contain
> "responder-measurements signing".
>
> This custom log format was chosen for lack of a better alternative.
> Although the TCG PFP Specification defines DEVICE_SECURITY_EVENT_DATA
> structures, those structures do not store the transcript (which can be
> a few kBytes or up to several MBytes in size). They do store nonces,
> hence at least allow for verification of nonce freshness. But without
> the transcript, user space cannot verify the signature:
>
> https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/
>
> Exposing the transcript as an attribute of its own has the benefit that
> it can directly be fed into a protocol dissector for debugging purposes
> (think Wireshark).
>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
> Cc: Jérôme Glisse <jglisse@google.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
Nice - particularly the thorough ABI docs. A few trivial comments inline.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> +/**
> + * spdm_create_log_entry() - Allocate log entry for one received SPDM signature
> + *
> + * @spdm_state: SPDM session state
> + * @spdm_context: SPDM context (needed to create combined_spdm_prefix)
> + * @slot: Slot which was used to generate the signature
> + * (needed to create certificate_chain symlink)
> + * @req_nonce_off: Requester nonce offset within the transcript
> + * @rsp_nonce_off: Responder nonce offset within the transcript
> + *
> + * Allocate and populate a struct spdm_log_entry upon device authentication.
> + * Publish it in sysfs if the device has already been registered through
> + * device_add().
> + */
> +void spdm_create_log_entry(struct spdm_state *spdm_state,
> + const char *spdm_context, u8 slot,
> + size_t req_nonce_off, size_t rsp_nonce_off)
> +{
> + struct spdm_log_entry *log = kmalloc(sizeof(*log), GFP_KERNEL);
> + if (!log)
> + return;
> +
> + *log = (struct spdm_log_entry) {
> + .slot = slot,
> + .version = spdm_state->version,
> + .counter = spdm_state->log_counter,
> + .list = LIST_HEAD_INIT(log->list),
> +
> + .sig = {
> + .attr.name = log->sig_name,
> + .attr.mode = 0444,
> + .read = sysfs_bin_attr_simple_read,
> + .private = spdm_state->transcript_end -
> + spdm_state->sig_len,
> + .size = spdm_state->sig_len },
We might set other bin_attr callbacks sometime in future, so I would
add the trailing comma and move the }, to the next line for these.
> +
> + .req_nonce = {
> + .attr.name = log->req_nonce_name,
> + .attr.mode = 0444,
> + .read = sysfs_bin_attr_simple_read,
> + .private = spdm_state->transcript + req_nonce_off,
> + .size = SPDM_NONCE_SZ },
> +
> + .rsp_nonce = {
> + .attr.name = log->rsp_nonce_name,
> + .attr.mode = 0444,
> + .read = sysfs_bin_attr_simple_read,
> + .private = spdm_state->transcript + rsp_nonce_off,
> + .size = SPDM_NONCE_SZ },
> +
> + .transcript = {
> + .attr.name = log->transcript_name,
> + .attr.mode = 0444,
> + .read = sysfs_bin_attr_simple_read,
> + .private = spdm_state->transcript,
> + .size = spdm_state->transcript_end -
> + spdm_state->transcript -
> + spdm_state->sig_len },
> +
> + .combined_prefix = {
> + .attr.name = log->combined_prefix_name,
> + .attr.mode = 0444,
> + .read = spdm_read_combined_prefix,
> + .private = log,
> + .size = spdm_state->version <= 0x11 ? 0 :
> + SPDM_COMBINED_PREFIX_SZ },
> +
> + .spdm_context = {
> + .attr.attr.name = log->spdm_context_name,
> + .attr.attr.mode = 0444,
> + .attr.show = device_show_string,
> + .var = (char *)spdm_context },
> +
> + .hash_alg = {
> + .attr.attr.name = log->hash_alg_name,
> + .attr.attr.mode = 0444,
> + .attr.show = device_show_string,
> + .var = (char *)spdm_state->base_hash_alg_name },
> + };
> +
> + snprintf(log->sig_name, sizeof(log->sig_name),
> + "%u_signature", spdm_state->log_counter);
> + snprintf(log->req_nonce_name, sizeof(log->req_nonce_name),
> + "%u_requester_nonce", spdm_state->log_counter);
> + snprintf(log->rsp_nonce_name, sizeof(log->rsp_nonce_name),
> + "%u_responder_nonce", spdm_state->log_counter);
> + snprintf(log->transcript_name, sizeof(log->transcript_name),
> + "%u_transcript", spdm_state->log_counter);
> + snprintf(log->combined_prefix_name, sizeof(log->combined_prefix_name),
> + "%u_combined_spdm_prefix", spdm_state->log_counter);
> + snprintf(log->spdm_context_name, sizeof(log->spdm_context_name),
> + "%u_type", spdm_state->log_counter);
> + snprintf(log->hash_alg_name, sizeof(log->hash_alg_name),
> + "%u_hash_algorithm", spdm_state->log_counter);
> +
> + sysfs_bin_attr_init(&log->sig);
> + sysfs_bin_attr_init(&log->req_nonce);
> + sysfs_bin_attr_init(&log->rsp_nonce);
> + sysfs_bin_attr_init(&log->transcript);
> + sysfs_bin_attr_init(&log->combined_prefix);
> + sysfs_attr_init(&log->spdm_context.attr.attr);
> + sysfs_attr_init(&log->hash_alg.attr.attr);
> +
> + list_add_tail(&log->list, &spdm_state->log);
> + spdm_state->log_counter++;
Sanity check for roll over maybe?
> +
> + /* Steal transcript pointer ahead of spdm_free_transcript() */
> + spdm_state->transcript = NULL;
> +
> + if (device_is_registered(spdm_state->dev))
> + spdm_publish_log_entry(&spdm_state->dev->kobj, log);
> +}
> +
> +/**
> + * spdm_publish_log() - Publish log of received SPDM signatures in sysfs
> + *
> + * @spdm_state: SPDM session state
> + *
> + * sysfs attributes representing received SPDM signatures are not static,
> + * but created dynamically upon authentication. If a device was authenticated
> + * before it became visible in sysfs, the attributes could not be created.
> + * This function retroactively creates those attributes in sysfs after the
> + * device has become visible through device_add().
> + */
> +void spdm_publish_log(struct spdm_state *spdm_state)
> +{
> + struct kobject *kobj = &spdm_state->dev->kobj;
> + struct kernfs_node *grp_kn __free(kernfs_put);
As in previous reviews I'd keep constructor with destructor by declaring
these inline.
> + struct spdm_log_entry *log;
> +
> + grp_kn = kernfs_find_and_get(kobj->sd, spdm_signatures_group.name);
> + if (WARN_ON(!grp_kn))
> + return;
> +
> + mutex_lock(&spdm_state->lock);
guard() perhaps.
> + list_for_each_entry(log, &spdm_state->log, list) {
> + struct kernfs_node *sig_kn __free(kernfs_put);
> +
> + /*
> + * Skip over log entries created in-between device_add() and
> + * spdm_publish_log() as they've already been published.
> + */
> + sig_kn = kernfs_find_and_get(grp_kn, log->sig_name);
> + if (sig_kn)
> + continue;
> +
> + spdm_publish_log_entry(kobj, log);
> + }
> + mutex_unlock(&spdm_state->lock);
> +}
> +EXPORT_SYMBOL_GPL(spdm_publish_log);
next prev parent reply other threads:[~2024-07-18 15:56 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 19:35 [PATCH v2 00/18] PCI device authentication Lukas Wunner
2024-06-30 19:36 ` [PATCH v2 01/18] X.509: Make certificate parser public Lukas Wunner
2024-07-10 2:46 ` Alistair Francis
2024-06-30 19:37 ` [PATCH v2 02/18] X.509: Parse Subject Alternative Name in certificates Lukas Wunner
2024-07-10 2:48 ` Alistair Francis
2024-06-30 19:38 ` [PATCH v2 03/18] X.509: Move certificate length retrieval into new helper Lukas Wunner
2024-07-10 2:49 ` Alistair Francis
2024-07-18 11:04 ` Jonathan Cameron
2024-06-30 19:39 ` [PATCH v2 04/18] certs: Create blacklist keyring earlier Lukas Wunner
2024-07-10 2:52 ` Alistair Francis
2024-06-30 19:40 ` [PATCH v2 05/18] crypto: akcipher - Support more than one signature encoding Lukas Wunner
2024-06-30 19:41 ` [PATCH v2 06/18] crypto: ecdsa - Support P1363 " Lukas Wunner
2024-06-30 22:10 ` Herbert Xu
2024-07-29 14:27 ` Lukas Wunner
2024-06-30 19:42 ` [PATCH v2 07/18] spdm: Introduce library to authenticate devices Lukas Wunner
2024-06-30 21:29 ` Jeff Johnson
2024-07-08 9:57 ` Alexey Kardashevskiy
2024-07-08 12:54 ` Lukas Wunner
2024-07-09 0:45 ` Alexey Kardashevskiy
2024-07-09 8:49 ` Lukas Wunner
2024-07-09 5:09 ` Dan Williams
2024-07-18 11:42 ` Jonathan Cameron
2024-07-09 15:00 ` Jeff Johnson
2024-07-18 14:24 ` Jonathan Cameron
2024-06-30 19:43 ` [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration Lukas Wunner
2024-07-09 18:10 ` Dan Williams
2024-07-09 19:32 ` Lukas Wunner
2024-07-09 23:31 ` Dan Williams
2024-07-11 15:00 ` Lukas Wunner
2024-07-11 17:50 ` Dan Williams
2024-07-12 0:50 ` Damien Le Moal
2024-07-14 8:42 ` Lukas Wunner
2024-07-15 17:21 ` Kees Cook
2024-07-15 18:12 ` Jason Gunthorpe
2024-07-15 20:36 ` Dan Williams
2024-07-15 22:02 ` Jason Gunthorpe
2024-07-15 22:17 ` Damien Le Moal
2024-07-15 23:03 ` Jason Gunthorpe
2024-07-15 23:26 ` Damien Le Moal
2024-07-15 23:42 ` Jason Gunthorpe
2024-07-15 23:57 ` Damien Le Moal
2024-07-16 0:11 ` Jason Gunthorpe
2024-07-16 1:23 ` Dan Williams
2024-07-15 22:50 ` Dan Williams
2024-07-15 23:21 ` Jason Gunthorpe
2024-07-15 23:37 ` Dan Williams
2024-07-15 23:55 ` Jason Gunthorpe
2024-07-16 1:35 ` Dan Williams
2024-07-22 10:19 ` Alexey Kardashevskiy
2024-07-22 12:06 ` Jason Gunthorpe
2024-07-23 4:26 ` Alexey Kardashevskiy
2024-07-23 12:58 ` Jason Gunthorpe
2024-07-15 20:19 ` Dan Williams
2024-07-15 20:08 ` Dan Williams
2024-06-30 19:44 ` [PATCH v2 09/18] PCI/CMA: Validate Subject Alternative Name in certificates Lukas Wunner
2024-07-10 20:35 ` Dan Williams
2024-06-30 19:45 ` [PATCH v2 10/18] PCI/CMA: Reauthenticate devices on reset and resume Lukas Wunner
2024-07-10 3:40 ` Alistair Francis
2024-07-10 23:23 ` Dan Williams
2024-07-18 15:01 ` Jonathan Cameron
2024-06-30 19:46 ` [PATCH v2 11/18] PCI/CMA: Expose in sysfs whether devices are authenticated Lukas Wunner
2024-07-17 23:17 ` Dan Williams
2024-07-18 15:11 ` Jonathan Cameron
2024-06-30 19:47 ` [PATCH v2 12/18] PCI/CMA: Expose certificates in sysfs Lukas Wunner
2024-07-18 2:43 ` Dan Williams
2024-07-18 15:16 ` Jonathan Cameron
2024-07-18 15:19 ` Jonathan Cameron
2024-06-30 19:48 ` [PATCH v2 13/18] sysfs: Allow bin_attributes to be added to groups Lukas Wunner
2024-07-04 10:13 ` Greg Kroah-Hartman
2024-07-12 3:49 ` Alistair Francis
2024-07-18 15:22 ` Jonathan Cameron
2024-06-30 19:49 ` [PATCH v2 14/18] sysfs: Allow symlinks to be added between sibling groups Lukas Wunner
2024-07-04 10:14 ` Greg Kroah-Hartman
2024-07-18 15:36 ` Jonathan Cameron
2024-06-30 19:50 ` [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs Lukas Wunner
2024-07-18 15:56 ` Jonathan Cameron [this message]
2024-06-30 19:51 ` [PATCH v2 16/18] spdm: Limit memory consumed by log of received signatures Lukas Wunner
2024-07-18 16:03 ` Jonathan Cameron
2024-06-30 19:52 ` [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain Lukas Wunner
2024-07-18 16:08 ` Jonathan Cameron
2024-06-30 19:53 ` [PATCH v2 18/18] spdm: Allow control of next requester nonce through sysfs Lukas Wunner
2024-07-18 16:11 ` Jonathan Cameron
2024-07-08 9:47 ` [PATCH v2 00/18] PCI device authentication Alexey Kardashevskiy
2024-07-08 13:35 ` Lukas Wunner
2025-02-11 1:30 ` Alexey Kardashevskiy
2025-02-12 16:36 ` Lukas Wunner
2025-05-20 8:35 ` Alexey Kardashevskiy
2025-05-29 5:29 ` Alexey Kardashevskiy
2025-05-29 9:40 ` 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=20240718165627.000052bc@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=aik@amd.com \
--cc=alistair.francis@wdc.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=david.e.box@intel.com \
--cc=dhaval.giani@amd.com \
--cc=dhowells@redhat.com \
--cc=dlemoal@kernel.org \
--cc=dwmw2@infradead.org \
--cc=gdhanuskodi@nvidia.com \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jgg@nvidia.com \
--cc=jglisse@google.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=ming4.li@intel.com \
--cc=pgonda@google.com \
--cc=sameo@rivosinc.com \
--cc=seanjc@google.com \
--cc=stern@rowland.harvard.edu \
--cc=wilfred.mallawa@wdc.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).