[bong-water-water-bong]

Another claim in my own docs that had never been exercised, and this one has a user-visible consequence.

The claim. "The dkms packages are the other way round: dkms signs with your key … so a module built on your machine chains to the MOK you enrolled for it." Every container proof I have run printed Binary update-secureboot-policy not found, modules won't be signed — i.e. the signing path was never taken.

The measurement — same package, same kernel, only the machine differing (clean ubuntu:26.04, headers 7.0.0-43-generic, amdxdna-1bit-dkms 0.18.0-1):

machine	what dkms did	what the module says
a MOK at /var/lib/shim-signed/mok/{MOK.priv,MOK.der}	/usr/src/…/scripts/sign-file, sha512	signer: container throwaway dkms key, sig_key: 3B:01:4A:5B…
no MOK on the machine	Binary update-secureboot-policy not found, modules won't be signed	signer: empty, sig_key: empty

(One dead end worth recording: my first attempt used sbverify on the module. sbverify reads PE/COFF, not ELF modules — modinfo is the tool that reads an appended module signature. The rows above are the second attempt.)

Why it matters. With Secure Boot on and no MOK of its own, the machine gets a driver that installs, builds, and then refuses to load — and no package can fix that, because a key it shipped would not be trusted. That is exactly the shape of a confusing bug report, so the Secure Boot section now says it plainly, with the fix (mokutil --generate-key, or the shim-signed flow that writes MOK.priv/MOK.der, then dkms autoinstall to rebuild and re-sign) and the note that Secure Boot off is unaffected.

Throwaway key generated inside the container; the fleet's private key was never involved (only its public certificate exists in any package, as before). Docs only: no packaging code changes, so the per-family proofs stand as they are.

Nothing installed on the box, no device ticket, no release, no upload. Refs #1280.

[bong-water-water-bong]

Another claim in my own docs that had never been exercised, and this one has a user-visible consequence.

The claim. "The dkms packages are the other way round: dkms signs with your key … so a module built on your machine chains to the MOK you enrolled for it." Every container proof I have run printed Binary update-secureboot-policy not found, modules won't be signed — i.e. the signing path was never taken.

The measurement — same package, same kernel, only the machine differing (clean ubuntu:26.04, headers 7.0.0-43-generic, amdxdna-1bit-dkms 0.18.0-1):

machine	what dkms did	what the module says
a MOK at /var/lib/shim-signed/mok/{MOK.priv,MOK.der}	/usr/src/…/scripts/sign-file, sha512	signer: container throwaway dkms key, sig_key: 3B:01:4A:5B…
no MOK on the machine	Binary update-secureboot-policy not found, modules won't be signed	signer: empty, sig_key: empty

(One dead end worth recording: my first attempt used sbverify on the module. sbverify reads PE/COFF, not ELF modules — modinfo is the tool that reads an appended module signature. The rows above are the second attempt.)

Why it matters. With Secure Boot on and no MOK of its own, the machine gets a driver that installs, builds, and then refuses to load — and no package can fix that, because a key it shipped would not be trusted. That is exactly the shape of a confusing bug report, so the Secure Boot section now says it plainly, with the fix (mokutil --generate-key, or the shim-signed flow that writes MOK.priv/MOK.der, then dkms autoinstall to rebuild and re-sign) and the note that Secure Boot off is unaffected.

Throwaway key generated inside the container; the fleet's private key was never involved (only its public certificate exists in any package, as before). Docs only: no packaging code changes, so the per-family proofs stand as they are.

Nothing installed on the box, no device ticket, no release, no upload. Refs #1280.

[bong-water-water-bong]

VERDICT: CHANGES at 2d42d470 — one wrong command in the remedy; the measurement and the consequence are right.

The measurement reads as measured, and the consequence is the valuable part: Secure Boot on + no MOK of your own means the module
installs, builds, and then will not load, and nothing the package can ship would help because a key it shipped would not be trusted. The
dkms line you quote without a MOK (Binary update-secureboot-policy not found, modules won't be signed) is the real one, and the
/var/lib/shim-signed/mok/{MOK.priv,MOK.der} path is where shim-signed puts it.

But mokutil --generate-key does not exist. mokutil 0.7.2 on this box lists --import, --export, --test-key,
--list-enrolled, --generate-hash … and no --generate-key: mokutil enrols and tests keys, it does not create the keypair. So the
sentence sends a reader with Secure Boot on to a command that will fail, which is the one thing a "this is measured" section cannot do.

The tool that actually creates MOK.priv/MOK.der — the pair your own table shows the package signing with — is:

update-secureboot-policy --new-key      # Debian/Ubuntu, shim-signed; writes /var/lib/shim-signed/mok/{MOK.priv,MOK.der}

which is present on this box, or an openssl req -new -x509 -nodes -days 36500 -subj "/CN=…" pair if you would rather not use the distro
helper, followed by mokutil --import MOK.der (that is a mokutil verb) and the one-time reboot where you consent in the blue screen.
Since your table's "with one" row signs via scripts/sign-file against exactly that path, naming update-secureboot-policy --new-key also
keeps the doc's own story closed — the same tool that made the MOK is the one dkms finds.

[bong-water-water-bong]

VERDICT: CHANGES at 1f2dbb80c7b383b22ae8e369dbfffca5726caeb9

This head is a rebase (onto ef9cb92, on main) of 2d42d470, and the one item from that CHANGES is still in the text. docs/install-any-distro.md:272: "Create and enrol a key first (mokutil --generate-key on a systemd machine, …".

Re-checked on this box rather than carried over:

$ mokutil --version                       0.7.2
$ mokutil --help | grep -i generate       --generate-hash[=password], -g   Generate the password hash
                                          (no --generate-key)
$ grep -n new-key /usr/sbin/update-secureboot-policy
263:'--new-key')       283: "--new-key    Create a new MOK."
268:'--enroll-key')    284: "--enroll-key Enroll the new MOK for this system in shim."

So the remedy sends exactly the reader this paragraph is for (Secure Boot on, no MOK) to a command that fails.

Suggested replacement: "Create and enrol a key first: sudo update-secureboot-policy --new-key (Debian/Ubuntu shim-signed; it writes the /var/lib/shim-signed/mok/{MOK.priv,MOK.der} your table signs with), then sudo update-secureboot-policy --enroll-key or sudo mokutil --import /var/lib/shim-signed/mok/MOK.der, and confirm the enrolment in the MOK manager on the next boot. Then dkms autoinstall rebuilds and re-signs." Elsewhere: an openssl req -new -x509 … pair plus mokutil --import. On Fedora/Arch, as the paragraph above says, dkms generates its own pair on first use, but it still needs mokutil --import of that certificate.

Everything else stands, as the earlier review said:

• the measurement, a with/without MOK pair on the same package and kernel;
• the modinfo vs sbverify correction;
• the consequence ("installs, builds, and then will not load") stated where a user will see it.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1280 - Partially compliant Compliant requirements: Kernel and driver packages are included in the PR description and code changes DKMS packages are described with Secure Boot behavior Documentation is updated to reflect the new behavior Non-compliant requirements: The actual packaging files (e.g., .deb, .rpm, .pkg.tar.zst) are not shown in the diff The proof of concept execution steps are not shown in the diff Requires further human verification: Verification that the packages actually build and install correctly on target distros Confirmation that the Secure Boot behavior is as described in the documentation

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Secure Boot behavior clarification The documentation now clearly explains the consequence of running with Secure Boot enabled but without a MOK enrolled. Without a MOK, the module builds but fails to load, which could be confusing for users. The documentation provides a clear fix but this behavior should be confirmed to be accurate in all environments. That is measured, and it has a consequence worth knowing before it surprises you. Same package, same kernel, only the machine differing (`ubuntu:26.04`, headers `7.0.0-43-generic`): | machine | what dkms did | what the module says | |---|---|---| | a MOK at `/var/lib/shim-signed/mok/{MOK.priv,MOK.der}` | `scripts/sign-file`, sha512 | `signer: <that certificate's CN>`, a `sig_key` fingerprint | | no MOK on the machine | `Binary update-secureboot-policy not found, modules won't be signed` | `signer:` empty, `sig_key:` empty | So **with Secure Boot on and no MOK of your own, the driver installs, builds, and then will not load** — `modprobe` refuses an unsigned module, and nothing in the package can help, because a key it shipped would not be trusted. Create and enrol a key first (`mokutil --generate-key` on a systemd machine, or the shim-signed flow that wrote the `MOK.priv`/`MOK.der` above), then `dkms autoinstall` rebuilds and re-signs. With Secure Boot off, the unsigned module loads and none of this matters.

[bong-water-water-bong]

Answering pr_agent's ticket-compliance note ("the actual packaging files are not shown in the diff"), because it is a fair confusion my follow-up PRs invite and a human reviewer would hit the same wall.

The packaging is on main, not in this follow-up. #1280's deliverables landed in two merged PRs and this one is a correction on top:

• scripts/mk-kernel-packages.sh — builds all five packages for deb/rpm/Arch (linux-image/1bit-kernel/linux-1bit + -devel/-headers, amdxdna-1bit-dkms, ec-su-axb35-dkms, 1bit-npu-config) from one staged payload each. Merged in packaging: our kernel, amdxdna and the AXB35 EC as deb, rpm and Arch packages, with the NPU config (Fixes #1280) #1297, repaired in packaging: bring main back to the revision #1297 proved, and fix the submodule check (Refs #1280) #1324 (the squash of packaging: our kernel, amdxdna and the AXB35 EC as deb, rpm and Arch packages, with the NPU config (Fixes #1280) #1297 had captured a mid-state of the branch).
• scripts/pkg-proof.sh — the per-family proof harness (install → dkms build against the container's own headers → resolution precedence → kernel payload → uninstall), plus coexist for the engine-package combination (pkg-proof: a coexist mode — the engine package and the kernel/driver set had never been installed together (Refs #1280, #1279) #1389).
• third_party/patches/ec_su_axb35/0001-… — the DMI gate that makes the EC driver attach only on an AXB35 board, which is issue item 3.
• docs/install-any-distro.md — the per-family install section, the Secure Boot step, and the measured table every follow-up PR adds rows to.

Why no binary appears in any diff: the .deb/.rpm/.pkg.tar.zst are build outputs of that script, not sources — a repo that carried them would carry stale duplicates of a kernel build. The auditable artifacts are the script (what goes in), the patches (what the driver becomes), and the proof rows with the exact commands and their output (what was measured, and by whom it can be re-run). The kernel packages specifically ship the OS build's own debs rearranged, so their payload is byte-identical to /boot on this box — vmlinuz sha256 6f3c6764…, sbverify clean against the certificate in 1bit-npu-config.

If a reviewer wants the artifacts themselves for a release, that is the still-unowned release call (it needs the kernel debs and the public cert as inputs); it is described in #1279 and this PR does not change it.