All of lore.kernel.org
 help / color / mirror / Atom feed
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);


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