From: "Dan Williams (nvidia)" <djbw@kernel.org>
To: Alison Schofield <alison.schofield@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jic23@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <iweiny@kernel.org>, Dan Williams <djbw@kernel.org>,
Li Ming <ming.li@zohomail.com>
Cc: linux-cxl@vger.kernel.org, Anisa Su <anisa.su@samsung.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal
Date: Thu, 25 Jun 2026 12:38:55 -0700 [thread overview]
Message-ID: <6a3d83cf9ee43_164f9d10042@djbw-dev.notmuch> (raw)
In-Reply-To: <20260619055932.1354182-1-alison.schofield@intel.com>
Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
>
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
>
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
>
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
>
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently extended to 10 and above.
Good find!
This is a good fix for folks with new kernels and old tooling, but
leaves folks with old kernels in the lurch.
Not sure of the priority of doing this additional work given it is not
clear the CXL PMEM devices with security commands ever shipped, but
userspace tooling can workaround this problem by always injecting both
an nvdimm:%llx and nvdimm:%lld formatted key descriptor.
For the kernel change:
Acked-by: Dan Williams <djbw@kernel.org>
next prev parent reply other threads:[~2026-06-25 19:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 5:59 [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal Alison Schofield
2026-06-22 16:19 ` Dave Jiang
2026-07-02 0:24 ` Alison Schofield
2026-06-25 11:37 ` Anisa Su
2026-06-25 19:38 ` Dan Williams (nvidia) [this message]
2026-07-02 0:26 ` Alison Schofield
2026-07-24 19:12 ` Dave Jiang
2026-07-24 20:19 ` Dave Jiang
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=6a3d83cf9ee43_164f9d10042@djbw-dev.notmuch \
--to=djbw@kernel.org \
--cc=alison.schofield@intel.com \
--cc=anisa.su@samsung.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=stable@vger.kernel.org \
--cc=vishal.l.verma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox