libnvme: no deterministic host identifier without root, or without DMI

[martin-belanger]

libnvmf_generate_hostid() tries DMI, then device-tree, then a random UUID. DMI is the only deterministic source, and it needs root: /sys/class/dmi/id/product_uuid and /sys/firmware/dmi/entries/*/raw are mode 0400. An unprivileged caller gets EACCES and the code silently falls through to libnvme_random_uuid(). So the same machine reports a stable identifier as root and a different one on every other call as a regular user.

Why that matters needs no elaboration here: targets gate access on the host NQN, and credentials are bound to it.

The scope is narrow, since anything that opens a controller needs root anyway. It is not empty: nvme gen-hostnqn touches no device, runs fine unprivileged, and answers differently every time with nothing saying why. Library consumers see the same.

Proposal

Add /etc/machine-id as the first source:

/etc/machine-id (derived) -> DMI -> device-tree -> random

/etc/machine-id is systemd's local machine identifier: 32 lowercase hex characters, 128 bits, written at installation or first boot and constant afterwards. It has been in systemd since v20 (commit d7ccca2e, March 2011) and every major distribution ships it. Man page: https://man7.org/linux/man-pages/man5/machine-id.5.html

It is mode 0444, so it is the only deterministic source an unprivileged caller can read. It is also the only one that works everywhere. DMI comes from PC firmware, so it exists on x86 and on ARM64 servers following SystemReady, but not on POWER, s390x, or embedded ARM and RISC-V boards. The device-tree fallback does not fill that gap: PATH_UUID_IBM is /proc/device-tree/ibm,partition-uuid (tree-linux.c:36), which covers IBM POWER LPARs only. Every other machine without DMI goes straight to a random UUID, whatever its privileges.

The raw value must not be used. systemd's documentation says the machine ID "must not be exposed in untrusted environments, in particular on the network", and that a machine-tied identifier must instead be derived by hashing it under a fixed, application-specific key. A host NQN is sent to the target and is visible across the fabric. The derivation is sd_id128_get_machine_app_specific(): HMAC-SHA256 keyed by a public application id, truncated to 128 bits, with the UUID variant and version bits set.

A second problem in the same function

uuid_from_product_uuid() validates the string length only (fabrics.c:236). A machine reporting an all-zero or all-FF System UUID, which is common on virtual machines and whitebox boards, gets that as its identifier, shared with every identical machine. Two hosts, one NQN, which is worse than a random value.

This validation used to exist. PR #654 (2020), which is where the DMI-first ordering came from, checked the UUID format and screened for fake vendor UUIDs by rejecting a value where one character dominates, which catches all-zeros and all-FFs. Neither check came along when the logic moved into C. Worth restoring, along with a log line naming the source that won.

Implementation

sd_id128_get_machine_app_specific() is a public libsystemd API, but I would not link it here. libnvme builds for Windows and for systems without systemd, and nvme-cli links libsystemd only for nvme-discoverd. Lifting the implementation avoids that, with precedent: shr_parse_time() in shared/time-util.c came from systemd, and shared/ carries the same LGPL-2.1-or-later license. systemd uses its own SHA-256 and HMAC rather than OpenSSL, so lifting also avoids gating this on CONFIG_OPENSSL, which shr_hmac_sha256() sits behind today.

Open question: should machine-id outrank DMI? machine-id identifies an installation, so it survives package upgrades and distribution upgrades but changes if the machine is reimaged; DMI identifies hardware and survives both. I lean toward machine-id first anyway, because with DMI first the same command returns different identifiers as root and as a normal user, and that split is silent.

[igaw]

There is some history on this: linux-nvme/libnvme#62. Adding a version of sd_id128_get_machine_app_specific() to shared is okay. We really should avoid adding a direct libsystemd dependency to libnvme or nvme-cli.

About the ordering: this is ultimately a policy question and depends on whom you ask. Thus, we should make it configurable via the global INI. We can pick the ‘security’ order as the default, while still allowing administrators to override the preference.

[martin-belanger]

Thanks. Agreed on libsystemd, and #62 is a useful citation — I will lift the derivation into shared/ rather than link.

On the ordering: I think the policy question goes away once the scope is narrowed, so I would rather not add the INI key.

I am only trying to harden nvme gen-hostnqn. Its output is useful only when it is written to /etc/nvme/hostnqn, which is 0755 root:root. A non-root run produces a value the caller cannot install. So the command should require root and return an error otherwise, instead of silently returning a random UUID.

With that, DMI is reachable whenever it exists, and DMI is always preferred: it is hardware-tied and stable for the life of the machine. machine-id identifies an installation, so it belongs after the firmware sources, not ahead of them. The chain becomes:

DMI -> device-tree -> machine-id -> random

To be clear about the second entry, it reads /proc/device-tree/ibm,partition-uuid, which is the Open Firmware device tree — the firmware's own description of the hardware, the equivalent of DMI on platforms that have no DMI. On an IBM POWER LPAR it is the partition UUID assigned by the hypervisor. That is why it belongs alongside DMI and ahead of machine-id. The path we read today is IBM specific, so it covers POWER only, but it is the same class of source.

The existing chain is untouched and machine-id is inserted before the last entry. This corrects the proposal in the issue above, which had machine-id first. That ordering was written to work around the non-root case, and the root requirement addresses that case directly.

The root-check goes in the nvme gen-hostnqn command, not in libnvmf_generate_hostid(). The unit tests call the library function directly and CI runs them unprivileged.

Two other changes, both independent of the ordering:

• Validate the DMI value with shr_hostid_valid(). uuid_from_product_uuid() checks the string length only, so an all-zero or all-FF System UUID from a VM becomes the hostid and is shared by every identical machine.
• Log which source won. "No DMI on this platform" and "DMI present, no permission" are indistinguishable today. This goes to stderr, at DEBUG for the normal case and as a visible warning when the chain falls through to random. stdout stays reserved for the NQN itself, since a post-install script redirects it into /etc/nvme/hostnqn.

Out of scope here: what nvme connect should do when no deterministic hostnqn can be found. Adding machine-id does improve that path, since libnvmf_generate_hostid() is shared, but whether an unconfigured host should fail instead of using a random identity is a separate decision and I am leaving it open.

[igaw]

Which makes me wonder if we should error out if nvme gen-hostnqn is run as non root?

[martin-belanger]

Which makes me wonder if we should error out if nvme gen-hostnqn is run as non root?

That is exactly what I'm proposing.

[tbzatek]

Thanks for taking care of what I've been lazy to finish :-) linux-nvme/libnvme#956

[igaw]

Which makes me wonder if we should error out if nvme gen-hostnqn is run as non root?

That is exactly what I'm proposing.

That was lost in the wall of text... :)

[tbzatek]

Open question: should machine-id outrank DMI? machine-id identifies an installation, so it survives package upgrades and distribution upgrades but changes if the machine is reimaged; DMI identifies hardware and survives both. I lean toward machine-id first anyway, because with DMI first the same command returns different identifiers as root and as a normal user, and that split is silent.

@johnmeneghini may have an opinion on this