From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: <bhelgaas@google.com>, <lukas@wunner.de>,
<rust-for-linux@vger.kernel.org>, <akpm@linux-foundation.org>,
<linux-pci@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <alex.gaynor@gmail.com>,
<benno.lossin@proton.me>, <boqun.feng@gmail.com>,
<a.hindborg@kernel.org>, <gary@garyguo.net>,
<bjorn3_gh@protonmail.com>, <tmgross@umich.edu>,
<ojeda@kernel.org>, <wilfred.mallawa@wdc.com>,
<aliceryhl@google.com>, Alistair Francis <alistair@alistair23.me>
Subject: Re: [RFC v3 12/27] lib: rspdm: Support SPDM get_version
Date: Mon, 16 Mar 2026 17:16:35 +0000 [thread overview]
Message-ID: <20260316171635.00002bb8@huawei.com> (raw)
In-Reply-To: <CAKmqyKMUT__C=4Lo5BhjB_QoaGHHNHQvxLmL4xuB54U=Rm0nzg@mail.gmail.com>
>
> >
> > > + let addr = unaligned.wrapping_add(i as usize);
> > > + let version = (unsafe { core::ptr::read_unaligned::<u16>(addr) } >> 8) as u8;
> > Given the endian conversion below, this is correct, but I think leaving it as the __le16 until
> > here is better. We could also just pull out the correct byte and ignore the other one.
>
> Hmm... I'm not sure I follow.
>
> The SPDM spec describes this as a u16, so I'm reading the entire value
> and just taking the upper bits for the Major/Minor version
Miss read by me I think... Or tied up with endian conversion I think you
say you are getting rid of below.
>
> So I'm not sure what you think I should do differently?
>
> > It's a spec quirk that they decided to have it defined as a __le16 rather than u8[2] as
> > the fields are confined one byte or the other.
> >
> > I wonder if we should also reject any alpha versions? I.e. check the bottom 4 bits
> > are 0.
>
> Hmmm... That seems a bit unnecessary. Maybe a warning though?
Warning works for me.
>
> >
> > > +
> > > + if version >= self.version && version <= SPDM_MAX_VER {
> > > + self.version = version;
> > > + foundver = true;
> > > + }
> > > + }
> > > +
> > > + if !foundver {
> > > + pr_err!("No common supported version\n");
> > > + to_result(-(bindings::EPROTO as i32))?;
> > > + }
> > > +
> > > + Ok(())
> > > + }
> > > }
> > > diff --git a/lib/rspdm/validator.rs b/lib/rspdm/validator.rs
> > > index a0a3a2f46952..f69be6aa6280 100644
> > > --- a/lib/rspdm/validator.rs
> > > +++ b/lib/rspdm/validator.rs
> > > @@ -7,6 +7,7 @@
> > > //! Rust implementation of the DMTF Security Protocol and Data Model (SPDM)
> > > //! <https://www.dmtf.org/dsp/DSP0274>
> > >
> > > +use crate::bindings::{__IncompleteArrayField, __le16};
> > > use crate::consts::SpdmErrorCode;
> > > use core::mem;
> > > use kernel::prelude::*;
> > > @@ -15,6 +16,8 @@
> > > validate::{Unvalidated, Validate},
> > > };
> > >
> > > +use crate::consts::SPDM_GET_VERSION;
> > > +
> > > #[repr(C, packed)]
> > > pub(crate) struct SpdmHeader {
> > > pub(crate) version: u8,
> > > @@ -64,3 +67,67 @@ pub(crate) struct SpdmErrorRsp {
> > > pub(crate) error_code: SpdmErrorCode,
> > > pub(crate) error_data: u8,
> > > }
> > > +
> > > +#[repr(C, packed)]
> >
> > Why packed?
>
> We cast it from a struct to a slice (array), so we need it to be
> packed to avoid gaps in the slice (array)
Ah ok. I'm learning slowly...
>
> >
> > > +pub(crate) struct GetVersionReq {
> > > + pub(crate) version: u8,
> > > + pub(crate) code: u8,
> > > + pub(crate) param1: u8,
> > > + pub(crate) param2: u8,
> > > +}
> > > +
> > > + // undefined behaviour, so we operate on the raw data directly
> > > + let unaligned = core::ptr::addr_of_mut!(rsp.version_number_entries) as *mut u16;
> > > + for version_offset in 0..version_number_entries {
> > > + let addr = unaligned.wrapping_add(version_offset);
> > > + let version = unsafe { core::ptr::read_unaligned::<u16>(addr) };
> > > + unsafe { core::ptr::write_unaligned::<u16>(addr, version.to_le()) }
> >
> > I'd like to see a comment on why this seems to be doing an endian swap if we
> > are on big endian. Looking back at the c code, it has an endian swap but
> > only as part of the search for a version to use (finding the largest both
> > device and and kernel support).
> >
> > Maybe I'm reading it wrong but isn't this putting cpu endian data into a structure
> > element that is of type __le16?
>
> On second thought I don't think this is required at all. It's
> converting the LE data from the SPDM response to LE. Which is just
> unnecessary no-op (LE) or a bug (BE) depending on the CPU endianness.
I think that makes sense but I'll take a close look at v4.
J
>
> Alistair
>
> >
> > > + }
> > > +
> > > + Ok(rsp)
> > > + }
> > > +}
> >
next prev parent reply other threads:[~2026-03-16 17:16 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-11 3:29 [RFC v3 00/27] lib: Rust implementation of SPDM alistair23
2026-02-11 3:29 ` [RFC v3 01/27] rust: add untrusted data abstraction alistair23
2026-02-11 3:29 ` [RFC v3 02/27] X.509: Make certificate parser public alistair23
2026-02-11 3:29 ` [RFC v3 03/27] X.509: Parse Subject Alternative Name in certificates alistair23
2026-02-11 3:29 ` [RFC v3 04/27] X.509: Move certificate length retrieval into new helper alistair23
2026-02-11 3:29 ` [RFC v3 05/27] certs: Create blacklist keyring earlier alistair23
2026-02-11 3:29 ` [RFC v3 06/27] rust: add bindings for hash.h alistair23
2026-02-19 14:48 ` Gary Guo
2026-03-02 16:18 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 07/27] rust: error: impl From<FromBytesWithNulError> for Kernel Error alistair23
2026-02-19 14:49 ` Gary Guo
2026-03-13 2:20 ` Alistair Francis
2026-03-13 10:35 ` Alice Ryhl
2026-02-11 3:29 ` [RFC v3 08/27] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-03-02 17:09 ` Jonathan Cameron
2026-03-13 3:44 ` Alistair Francis
2026-02-11 3:29 ` [RFC v3 09/27] PCI/CMA: Authenticate devices on enumeration alistair23
2026-02-16 4:25 ` Aksh Garg
2026-02-11 3:29 ` [RFC v3 10/27] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-02-11 3:29 ` [RFC v3 11/27] PCI/CMA: Reauthenticate devices on reset and resume alistair23
2026-02-11 3:29 ` [RFC v3 12/27] lib: rspdm: Support SPDM get_version alistair23
2026-02-11 4:00 ` Wilfred Mallawa
2026-03-03 11:36 ` Jonathan Cameron
2026-03-13 5:35 ` Alistair Francis
2026-03-13 5:53 ` Miguel Ojeda
2026-03-13 5:55 ` Miguel Ojeda
2026-03-16 17:16 ` Jonathan Cameron [this message]
2026-02-11 3:29 ` [RFC v3 13/27] lib: rspdm: Support SPDM get_capabilities alistair23
2026-02-11 4:08 ` Wilfred Mallawa
2026-03-03 12:09 ` Jonathan Cameron
2026-03-03 18:07 ` Miguel Ojeda
2026-03-20 4:32 ` Alistair Francis
2026-02-11 3:29 ` [RFC v3 14/27] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-03-03 13:46 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 15/27] lib: rspdm: Support SPDM get_digests alistair23
2026-03-03 14:29 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 16/27] lib: rspdm: Support SPDM get_certificate alistair23
2026-03-03 14:51 ` Jonathan Cameron
2026-03-31 2:37 ` Alistair Francis
2026-03-31 13:19 ` Gary Guo
2026-02-11 3:29 ` [RFC v3 17/27] crypto: asymmetric_keys - Load certificate parsing early in boot alistair23
2026-02-11 3:29 ` [RFC v3 18/27] KEYS: Load keyring and certificates " alistair23
2026-02-11 3:29 ` [RFC v3 19/27] PCI/CMA: Support built in X.509 certificates alistair23
2026-02-11 3:29 ` [RFC v3 20/27] crypto: sha: Load early in boot alistair23
2026-03-03 14:52 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 21/27] crypto: ecdsa: " alistair23
2026-03-03 14:54 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 22/27] lib: rspdm: Support SPDM certificate validation alistair23
2026-03-03 15:00 ` Jonathan Cameron
2026-03-31 3:29 ` Alistair Francis
2026-03-31 10:11 ` Miguel Ojeda
2026-04-01 1:48 ` Alistair Francis
2026-04-01 10:37 ` Miguel Ojeda
2026-02-11 3:29 ` [RFC v3 23/27] rust: allow extracting the buffer from a CString alistair23
2026-02-19 14:50 ` Gary Guo
2026-02-11 3:29 ` [RFC v3 24/27] lib: rspdm: Support SPDM challenge alistair23
2026-03-03 16:54 ` Jonathan Cameron
2026-02-11 3:29 ` [RFC v3 25/27] PCI/CMA: Expose in sysfs whether devices are authenticated alistair23
2026-02-11 3:29 ` [RFC v3 26/27] rust: add bindings for hash_info alistair23
2026-02-11 3:29 ` [RFC v3 27/27] rspdm: Multicast received signatures via netlink alistair23
2026-02-19 10:19 ` Lukas Wunner
2026-02-12 5:56 ` [RFC v3 00/27] lib: Rust implementation of SPDM dan.j.williams
2026-02-18 2:12 ` Alistair Francis
2026-04-09 3:39 ` Alistair Francis
2026-04-13 5:42 ` Alistair Francis
2026-04-17 2:35 ` Dan Williams
2026-04-17 4:34 ` Lukas Wunner
2026-04-17 5:20 ` Alistair Francis
2026-05-02 1:34 ` Dan Williams (nvidia)
2026-05-05 8:56 ` Alistair Francis
2026-02-17 23:56 ` Jason Gunthorpe
2026-02-18 2:17 ` Alistair Francis
2026-02-18 23:40 ` dan.j.williams
2026-02-19 0:56 ` Jason Gunthorpe
2026-02-19 5:05 ` dan.j.williams
2026-02-19 12:41 ` Jason Gunthorpe
2026-02-19 14:15 ` Lukas Wunner
2026-02-19 14:31 ` Jason Gunthorpe
2026-02-19 15:07 ` Lukas Wunner
2026-02-19 17:39 ` Jason Gunthorpe
2026-02-19 20:07 ` dan.j.williams
2026-02-20 8:30 ` Lukas Wunner
2026-02-20 14:10 ` Jason Gunthorpe
2026-02-21 18:46 ` Lukas Wunner
2026-02-21 23:29 ` dan.j.williams
2026-02-23 17:15 ` Jonathan Cameron
2026-02-23 19:11 ` dan.j.williams
2026-02-24 14:33 ` Jason Gunthorpe
2026-03-05 4:17 ` dan.j.williams
2026-03-05 12:48 ` Jason Gunthorpe
2026-03-05 19:49 ` dan.j.williams
2026-03-09 11:39 ` Jonathan Cameron
2026-03-09 12:31 ` Jason Gunthorpe
2026-03-09 15:33 ` Jonathan Cameron
2026-03-09 15:59 ` Jason Gunthorpe
2026-03-09 18:00 ` Jonathan Cameron
2026-03-09 20:40 ` Jason Gunthorpe
2026-03-09 23:11 ` DanX Williams
2026-02-24 14:16 ` Jason Gunthorpe
2026-02-24 15:54 ` Lukas Wunner
2026-02-25 14:50 ` Jason Gunthorpe
2026-02-19 14:40 ` Greg KH
2026-02-20 7:46 ` Lukas Wunner
2026-02-20 9:14 ` Greg KH
2026-02-20 11:45 ` Lukas Wunner
2026-02-20 11:57 ` Greg KH
2026-02-19 9:34 ` Lukas Wunner
2026-02-19 12:43 ` Jason Gunthorpe
2026-02-19 18:48 ` dan.j.williams
2026-02-19 9:13 ` Lukas Wunner
2026-02-19 18:42 ` dan.j.williams
2026-02-19 11:24 ` Jonathan Cameron
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=20260316171635.00002bb8@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.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.