Re: [PATCH v2 1/3] cxl/pmem: Format the nvdimm serial number as unsigned decimal

On Fri, Jul 03, 2026 at 02:28:25PM +0800, Richard Cheng wrote:
> On Wed, Jul 01, 2026 at 05:30:44PM +0800, Alison Schofield wrote:
> > The CXL NVDIMM security passphrase key description and the nvdimm 'id'
> > sysfs attribute are both derived from the CXL device serial number,
> > but the serial number is not formatted consistently.
> > 
> > The key description is formatted in hexadecimal while the 'id'
> > attribute is formatted in decimal. As a result, ndctl stores the key
> > using a decimal description while the kernel later looks it up using
> > a hexadecimal description. For serial numbers of 10 and above, the
> > descriptions no longer match, preventing automatic unlock after
> > reboot.
> > 
> > The decimal formatting has a second problem. Both the key description
> > and the 'id' attribute use the signed %lld format for a u64 PCIe
> > Device Serial Number. Devices whose vendor OUI sets bit 63, such as
> > Montage CXL devices, appear with negative decimal serial numbers.
> > 
> > Format the security key description and 'id' attribute as unsigned
> > decimal, %llu, and document that the 'id' attribute is an unsigned
> > decimal value.
> > 
> > The key lookup mismatch was exposed by CXL unit test cxl-security.sh
> > when cxl_test mock serial numbers were extended to 10 and above.
> > 
> > Cc: <[email protected]>
> > Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> > Signed-off-by: Alison Schofield <[email protected]>
> > ---
> >  Documentation/ABI/testing/sysfs-bus-nvdimm |  3 ++-
> >  drivers/cxl/core/pmem.c                    | 10 ++++++----
> >  drivers/cxl/cxl.h                          |  3 ++-
> >  drivers/cxl/pmem.c                         |  2 +-
> >  4 files changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm
> > index 64eb8f4c6a41..46dafd8482b9 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-nvdimm
> > +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm
> > @@ -48,7 +48,8 @@ What:		/sys/bus/nd/devices/nmemX/cxl/id
> >  Date:		November 2022
> >  KernelVersion:	6.2
> >  Contact:	Dave Jiang <[email protected]>
> > -Description:	(RO) Show the id (serial) of the device. This is CXL specific.
> > +Description:	(RO) Show the id (serial) of the device, formatted as an
> > +		unsigned 64-bit decimal value. This is CXL specific.
> >  
> >  What:		/sys/bus/nd/devices/nmemX/cxl/provider
> >  Date:		November 2022
> > diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> > index 68462e38a977..5a3bb7e8a1f1 100644
> > --- a/drivers/cxl/core/pmem.c
> > +++ b/drivers/cxl/core/pmem.c
> > @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
> >  	dev->bus = &cxl_bus_type;
> >  	dev->type = &cxl_nvdimm_type;
> >  	/*
> > -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> > -	 * NVDIMM_KEY_DESC_LEN
> > +	 * dev_id is the nvdimm dimm_id used for security key lookup.
> > +	 * It must match id_show(), which emits the CXL serial as an
> > +	 * unsigned decimal. A u64 decimal string is at most 20 digits
> > +	 * plus NUL.
> >  	 */
> > -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> > +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
> >  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> > -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> > +	sprintf(cxl_nvd->dev_id, "%llu", cxlmd->cxlds->serial);
> > 
> 
> Hi Alison,
> 
> How should existing keys for high-bit serial numbers be migrated?
> 
> This patch changes both the sysfs  ID and kernel key description to unsigned
> decimal. ndctl persists the old sysfs string in the key-blob filename and reloads it unchanged.
> 
> I wonder how's the old key being migrated ? I don't think the patch rename files under /etc/ndctl/keys , so ndctl may reload the existing secret
> while the new kernel searches for the positive new label.

Thanks for the review. I want to add this case to the documented work-
around. I think that the exposure of this issue is very low because
of the lack of CXL pmem out in the wild. Let me know if you had other
thoughts on that belief, becuase that is what drivers me towards
documenting only, and not supply a command or script within the
ndctl tooling to do the migration.

So, only one class of key actually needs action on upgrade: a serial with
bit 63 set, which was saved under a negative-decimal description and
is now requested as unsigned decimal. Serials >= 10 without bit 63 set
never auto-unlocked on the old kernel (the original bug) and are already
named by the positive decimal the fixed kernel requests, so they need no
action.

The one-time re-stage for the bit-63 case is documented  in the work-
around now. Appending that here for reference.


CXL nvdimm auto-unlock: serial-number key-description mismatch
==============================================================

A passphrase-protected CXL nvdimm may fail to auto-unlock after a reboot,
staying "locked" so that the pmem namespaces it backs do not come up. The
cause is a serial-number formatting mismatch between the kernel and ndctl:
the kernel looked the security key up by a hex-formatted serial, while
ndctl saved and named the key blob by the decimal serial. The two spellings
differ for any serial of 10 or greater, so the key the kernel requests is
never found. A second formatting problem affects serials with bit 63 set
(for example Montage devices): the decimal serial was formatted as signed,
so it rendered as a negative value.

This is fixed in Linux 7.3 and later, which format the serial as unsigned
decimal consistently in both the key description and the 'id' attribute.
See commit <TBD-COMMIT> ("cxl/pmem: Format the nvdimm serial number as
unsigned decimal").

This document covers two situations:

- Recovering a dimm on a kernel that still lacks the fix.
- Migrating an already-enrolled key after upgrading to the fixed kernel.


Manual recovery (kernel that lacks the fix)
-------------------------------------------

If a passphrase-protected CXL nvdimm does not auto-unlock after a reboot
-- it stays "locked" and the pmem namespaces it backs do not come up --
use the following to recover on a kernel that lacks the serial fix.

1. Confirm the device is actually locked, and that auto-unlock is what
   failed (not, say, a missing key blob or a hardware/security state
   issue):

     ndctl list -i -d nmemX | jq -r '.[].dimms[0].security'

   This should report "locked". If it reports "disabled" the device has
   no passphrase enrolled and this is a different problem; if it reports
   "unlocked" there is nothing to recover.

2. Confirm the failure is the serial-number format mismatch. The kernel
   looks the key up by a hex-formatted serial, while ndctl saved and
   named it by the decimal serial. They differ for any serial of 10 or
   greater. Compare the two spellings of this device's serial:

     # decimal serial, as ndctl named the key:
     cat /sys/bus/nd/devices/nmemX/cxl/id

     # hex serial, as the kernel looks it up:
     cat /sys/bus/cxl/devices/memY/serial

   If the decimal 'id' is 10 or greater (the hex and decimal forms are
   not the same string), you are hitting this issue. Confirm the key
   blob ndctl saved exists, named by the decimal serial:

     id=$(cat /sys/bus/nd/devices/nmemX/cxl/id)
     ls /etc/ndctl/keys/nvdimm_${id}_$(hostname).blob

   If that blob is missing, the key was never saved and this recovery
   does not apply -- re-enroll the passphrase instead.

3. Stage the same key blob under the hex-formatted serial so that
   load-keys also installs the key the kernel asks for:

     id=$(cat /sys/bus/nd/devices/nmemX/cxl/id)
     hexid=$(printf '%x' "$id")
     host=$(hostname)
     cp /etc/ndctl/keys/nvdimm_${id}_${host}.blob \
        /etc/ndctl/keys/nvdimm_${hexid}_${host}.blob

4. Reload the keys and bring the device up. load-keys derives the key
   description from the blob file name, so the copy is installed as the
   nvdimm:<hex> key the kernel requests:

     ndctl load-keys
     ndctl enable-dimm nmemX

   The device should now report "unlocked":

     ndctl list -i -d nmemX | jq -r '.[].dimms[0].security'

Verified against cxl_test on an unpatched kernel: the dimm unlocks.


Migration after upgrading to the fixed kernel
---------------------------------------------

The recovery above is for a kernel that lacks the fix. After upgrading
to the fixed kernel, one class of already-enrolled key must be migrated.

The fix formats the serial as unsigned decimal (%llu) for both the key
description and the 'id' attribute. The only keys affected on upgrade are
those for a serial with bit 63 set (for example a Montage device): before
the fix id_show() emitted the serial as signed decimal, so ndctl named
the key blob by a negative string, while the fixed kernel now requests
the key by the unsigned decimal. The existing blob is not found and the
dimm fails to auto-unlock.

Serials without bit 63 set need no action. ndctl already named the blob
by the positive decimal the fixed kernel now requests, so they
auto-unlock after the upgrade with no migration.

To migrate a bit-63 serial, stage the existing blob under the unsigned
decimal name the fixed kernel requests. The old blob is already on disk
named by the negative decimal the previous kernel emitted, so locate it
rather than recompute it:

     # unsigned decimal serial, as the fixed kernel now looks it up:
     id=$(cat /sys/bus/nd/devices/nmemX/cxl/id)
     host=$(hostname)

     # the existing blob, named by the old negative decimal:
     ls /etc/ndctl/keys/nvdimm_-*_${host}.blob

     cp /etc/ndctl/keys/nvdimm_<negative-id>_${host}.blob \
        /etc/ndctl/keys/nvdimm_${id}_${host}.blob

Reload the keys and bring the device up. load-keys derives the key
description from the blob file name, so the copy is installed as the
nvdimm:<unsigned-decimal> key the fixed kernel requests:

     ndctl load-keys
     ndctl enable-dimm nmemX

   The device should now report "unlocked":

     ndctl list -i -d nmemX | jq -r '.[].dimms[0].security'



> 
> --Richard
>  
> >  	return cxl_nvd;
> >  }
> > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> > index c0e5308e4d1b..d683ae5e0f7d 100644
> > --- a/drivers/cxl/cxl.h
> > +++ b/drivers/cxl/cxl.h
> > @@ -503,7 +503,8 @@ struct cxl_nvdimm_bridge {
> >  	struct nvdimm_bus_descriptor nd_desc;
> >  };
> >  
> > -#define CXL_DEV_ID_LEN 19
> > +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
> > +#define CXL_DEV_ID_LEN 21
> >  
> >  enum {
> >  	CXL_NVD_F_INVALIDATED = 0,
> > diff --git a/drivers/cxl/pmem.c b/drivers/cxl/pmem.c
> > index 261dff7ced9f..a9f50281875d 100644
> > --- a/drivers/cxl/pmem.c
> > +++ b/drivers/cxl/pmem.c
> > @@ -52,7 +52,7 @@ static ssize_t id_show(struct device *dev, struct device_attribute *attr, char *
> >  	struct cxl_nvdimm *cxl_nvd = nvdimm_provider_data(nvdimm);
> >  	struct cxl_dev_state *cxlds = cxl_nvd->cxlmd->cxlds;
> >  
> > -	return sysfs_emit(buf, "%lld\n", cxlds->serial);
> > +	return sysfs_emit(buf, "%llu\n", cxlds->serial);
> >  }
> >  static DEVICE_ATTR_RO(id);
> >  
> > -- 
> > 2.37.3
> > 
> > 
>