MELBOURNE RHUG · OCTOBER 2026

How much OS trust can you bake in at day 0?

A field report from a homelab, with receipts.

Andrew Dunn · GitLab working title · draft every link in this deck is public

02THE HOOK

My phone updates itself overnight.
My servers still get patched by hand.

My phone

One image, built and tested before it ships
Updates overnight, atomically
Rolls back by itself when something is wrong
Nobody patches it by hand

Millions of devices · one image · no hands

My servers

Installed once, then configured forever
Patched in place, host by host
Drifts, quietly, one edit at a time
Audited by scanning and reconciliation

Every host, its own snowflake

How much of the phone treatment can a server OS take, and how much of it can CI bake in before first boot?

03WHAT IS VERIFIED, WHAT IS WATCHED

Above the kernel, integrity rests on a baseline someone maintains.

Enforcement above the kernel exists, per file, against reference values someone regenerates.

Teach the grammar here and never break it: solid means enforced in the boot or read path, dashed means watched after the fact or writable by design. Secure Boot verifies firmware, bootloader, kernel, then hands over. Above that line regulated shops are not naive, and one of these is not detection at all. Tripwire invented file-integrity monitoring; agents hash files and ship evidence to a central console. SCAP sweeps run on schedule. IMA is two different things: measurement measures every read into the TPM and Keylime replays that log against policy at a verifier, which is detection; appraisal is enforcement. Red Hat's own words, RHEL 10 chapter 26: "IMA-Appraisal: Verify file integrity by comparing the calculated file hash with a known good reference value or by verifying a signature stored in the security.ima extended attribute" and "If verification fails, the system denies access." Their concrete demo: copy /usr/sbin/ip to /tmp and run it, and it returns Permission denied, because the copy lost its security.ima xattr. And "From RHEL 9, Red Hat signs all package files per file." So do not claim nobody enforces above the kernel. Three boundaries on that, all verified, and they are the argument rather than a footnote: it is Red Hat-built content only, so RHEL 8 carries no per-file signatures at all and EPEL packages carry none either; the signatures sit inert in the RPM signature header until rpm-plugin-ima is installed, which is not in @core and is required by nothing, after which every package has to be reinstalled to materialise the xattrs; and the code-signing cert arrives via ima-evm-utils, which the docs never name. The contrast that matters is what the enforcement is anchored to: appraisal reconciles per file against reference values that have to be generated for every governed file and regenerated on install and upgrade — their chapter 27.1 is literally titled "Generate good reference values for IMA appraisal". The question the rest of the talk chases: what if that baseline is one digest, computed at build time, covering the whole filesystem. This picture returns twice more, on the factory and the seal.

04THE LAY OF THE LAND

The moving parts, and who ships them.

None of these boxes is the feature on its own. The properties fall out of how they compose.

05THE FACTORY

I got CI to build the whole OS, drivers included.

The expensive part was the out-of-tree modules: compiled against the image's own kernel and signed in the same build.

06THE BOOT GATE

I gate promotion on a real boot.

boot-gate · in a VM · inside the pipeline

install this exact image to a disk ............ ok

boot it · reach a login prompt ................. ok

load zfs .............................................. ok

nvidia · signature accepted (no GPU on this VM) ... ok

promotion unlocked · :stable → this digest

THE ARTIFACT

The exact bytes, not a rebuild

THE INSTALL

A real install, to a real disk

THE BOOT

A real boot, to a login prompt

THE MODULES

zfs loaded, not just present

the same bytes that pass are the bytes that ship · a failed gate moves nothing

watch one:https://gitlab.com/dunn.dev/cairn/base/-/jobs/16417649382

that job: the boot gate on cairn/base main, 10 September 2026, green · the whole gate is one script and it is in the repo above · the run it belongs to is backup face B7

The gate tests the bytes that ship, not the recipe.

Promotion semantics, before the machinery: :stable is not a name someone assigns, it is a claim the pipeline earns. Four invariants, all against the artifact itself: this exact image installed to a disk, booted to a login prompt, and loaded zfs, in a VM, inside the pipeline; only then does the tag move to this digest. Be precise if asked: zfs must actually load, and nvidia must not be signature-rejected — the gate VM has no GPU, so "no such device" passes and a bad signature does not. Test the artifact, not the recipe: recipes drift from their outputs, bytes do not. The tag is a claim with history: every digest :stable has ever named is still in the registry with the serial log that earned it. The URL is the boot-gate job's own log from a real completed run; open it here if the room wants, nothing can fail live. The whole pipeline that job sits in is on backup face B7, where every job links its log. How that VM exists inside a CI job is the next face.

07THE RIG · A BOOT LAB INSIDE CI

The smoke test is a VM inside the job.

SaaS shared runners do not expose /dev/kvm · this is one small self-managed runner, doing one job · every state and edge above is sealed-boot.sh behavior

The runner host boots an image this same pipeline built.

The rig, outside in, then one run left to right. The nesting: the runner host's own OS is a whetstone golden image, a bootc qcow2 built from cairn/base by the pipeline it now serves; gitlab-runner exposes a rootful podman socket and hands the job /dev/kvm; the job routes by tags: [crucible] and the golden is read-only, qemu and swtpm baked in, nothing installs at job time. The flow is sealed-boot.sh verbatim. PULL records the candidate's digest. EXTRACT takes everything the gate trusts from the image itself: the UKI, the signing cert out of its Authenticode signature, and the composefs= digest on the signed command line; an image missing any of these dies here. ENROLL mints throwaway PK and KEK and builds an enforcing varstore whose db holds exactly my one cert, no Microsoft, no shim. On an MR the lane mints its own ephemeral keys per role, so the baked cert and the db cert differ there and the gate enrols both; on main they are the same certificate and it enrols one. INSTALL runs bootc install to-disk via loopback onto a fresh 20G raw disk; if the sealed root is not there afterward, red. BOOT starts swtpm and QEMU under enforcing Secure Boot and tails the serial console for up to ten minutes: the login prompt advances, and four things go red instead, a firmware verification refusal (Access Denied or Security Violation in the log), a kernel panic or verity failure, QEMU exiting early, or the clock running out. GATE drives assert-sealed.sh over SSH: Secure Boot on, lockdown integrity, the runtime composefs digest equal to the signed one, zfs loaded, nvidia's signature not rejected, the kmod signer resolving in .platform as cairn UKI signing. Two different reds here, and the distinction is worth keeping straight if someone asks: SSH unreachable for 120 seconds exits the script outright, with no verdict line at all, while a failed assertion comes back as VERDICT=FINDING. VERDICT=PASS is the only green: :stable moves to this digest. Every red path leaves receipts and the serial log as job artifacts, so a failure is a finding, not a mystery.

08THE SEAL

I sealed the image under one digest.

"What am I running?" · detection

Tripwire-class FIM · baseline database
IMA + Keylime · attest after the read
Patch management + inventory agents
Vulnerability scanner
SCAP compliance scans

All reconciliation, after the fact, against a baseline someone maintains.

Sealed image · enforcement

composefs = EROFS metadata + overlayfs + fs-verity objects the root digest rides in the signed UKI command line dm-verity seals a device · fs-verity seals files /etc and /var stay writable, by design

The baseline is now one digest I signed at build. The kernel checks it on every read.

09WHOSE KEYS, WHOSE MACHINE

What happened when I enrolled my own keys.

NSA · UEFI Secure Boot Customization · CTR v1.2 · §3.2:

https://media.defense.gov/2023/Mar/20/2003182401/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20230317.PDF

I took shim out, MOK went with it, and module trust moved into db.

The topology, top of the hierarchy first: PK, minted in a key ceremony, is the root; it signs the KEK; the KEK authorizes updates to db; db is what the firmware actually checks at power-on, and it verifies systemd-boot and the UKI. I enroll my own PK, KEK, and db. Microsoft's certificates stay in db, because my option ROMs are signed against them and I am not big enough to buy hardware signed with my keys, but nothing of theirs signs my boot chain. shim is not in the image, and MOK, the machine-owner-key mechanism, goes with shim. So module trust has to move somewhere; mine moved to my own signing key in db, applied to every .ko during the build, and the kernel trusts it at load because Fedora's kernel carries a downstream patch that trusts db for module signatures. I ran two workable arrangements and boot-tested both, a separate module key and the db key doing both jobs, and the estate ships the second one now: the module-signing key is gone, and one certificate signs systemd-boot, every UKI and every .ko. Here is the actual measurement, from lodestone on kernel 7.1.12-200.fc44, because this is the face where someone asks what is really in the keyring. keyctl list on the platform keyring returns five keys: my one signing certificate, cairn UKI signing, and four of Microsoft's, the Corporation UEFI CA 2011, the Windows Production PCA 2011, the UEFI CA 2023 and the Windows UEFI CA 2023. It read six until I took the retired module certificate out of db, live, from the running system: a KEK-signed authenticated payload written straight to efivarfs, no Setup Mode, no BIOS, no shim. The firmware took it and the next boot came up at five. The machine keyring is empty. Secondary trusted keys links builtin only. The blacklist carries 183 dbx entries. Two things follow, and the second is the stronger one. First, nothing was pruned, so the accurate claim is that the only loader on this disk is mine, not that the firmware would refuse a Microsoft-signed one; it would boot. Second, the module half is entirely mine: zfs and nvidia both load under lockdown integrity with signature enforcement on, and modinfo reports the signer as "cairn UKI signing", skid 00a896f3, the same certificate that verifies the UKI, and it exists in no keyring but the platform one. A db key is signing out-of-tree modules with no MOK anywhere in the picture, which is the whole arrangement the sidequest is about. If someone asks whether keeping Microsoft's certificates is a cop-out, NSA's own report is the reference for both halves, and the number to give if they want to look it up themselves is CTR U/OO/168873-20, Ver. 1.2, March 2023. Section 7.3 says the third-party marketplace CA signs storage controller firmware, graphics card firmware, UEFI driver modules and Linux bootloaders, which is exactly why mine stays. Section 3.2 gives the procedure for taking it out, in an insider-threat context: remove it from db, then add the individual hardware components, storage controller and network interfaces, to the db allow list as SHA-256 hashes. And that same section says removal distrusts all versions of Linux, because shim is signed by Microsoft. That is the point worth landing: I never had to take that trade, because shim is not in my image at all. One naming caution if pressed: "Microsoft UEFI Marketplace CA" is the report's own shorthand in 3.2, not a certificate common name. The same document calls it the UEFI Third Party Marketplace CA in 7.3, and NSA's December 2025 guidance calls it the Microsoft UEFI CA 2011. In my own keyring it appears as "Microsoft Corporation UEFI CA 2011", sitting beside its 2023 successor, so if anyone wants to map the report onto a real listing, that is the line it points at. That newer document is a companion, not a replacement, and it calls removing the CA unusual for exactly the shim reason. Which sets up the sidequest.

10SIDEQUEST · MODULE TRUST

Should my own key load a kernel module?

MAINLINE LINUX ✗

No

The platform keyring does not verify modules, deliberately. Four proposals since 2019: two rejected on principle, one died, and the 2025 RFC got no second version.

NEARLY EVERY DISTRO ✓

Yes

A downstream patch trusts the platform keyring for modules. Of 9 families I surveyed, 8 carry it.

MY LAB ⚖

Boot-tested both

Both directions, with a negative control. The behavior is real and load-bearing; the docs state the rule but never that it is a patch.

CARRY THE PLATFORM-KEYRING PATCH · 8 OF 9

Fedora · RHEL · Alma · Rocky · Ubuntu · Debian · SUSE · Oracle RHCK

MAINLINE .machine PATH ALONE · 1 OF 9

Oracle UEK 7/8. The split runs inside one vendor: Oracle's own RHCK carries the patch, UEK7 dropped it.

my RFE · .mokkeys · withdrawn, the why:https://github.com/systemd/systemd/pull/43638#issuecomment-5611922484

The behavior fleets rely on is a distro patch, and the docs state the rule without saying it is one.

A sidequest for the kernel people in the room. I signed my modules with the same key that signs my bootloader. Should they load? Mainline says no, and means it: the platform keyring is deliberately excluded from module verification. Get the history right, because someone here will know it. Four attempts since 2019, not three. Robert Holmes in 2019 and Michal Suchánek of SUSE in 2022 were both rejected on principle by Mimi Zohar, the integrity maintainer — her words, that the exclusion "was not neglected, but rather intentional". A 2023 attempt died after two replies. And the most recent one is the interesting one for this room: in June 2025 Vitaly Kuznetsov, at Red Hat, proposed CONFIG_MODULE_SIG_PLATFORM, and when asked directly whether the idea had been rejected before, James Bottomley said "well not rejected", and asked whether there is now a growing use case worth reconsidering. No v2 has appeared in fourteen months. So: stalled with the door open, not ruled out — do not tell this room upstream has settled it. Meanwhile eight of the nine families I surveyed carry the downstream patch that says yes, and Oracle is on both sides of its own split. Scope that honestly if pressed: nine families with mainline held as a control, and families are not uniform inside themselves — SLE12-SP5 on 4.12 does not carry it, and Oracle added it in UEK6u3 before dropping it from UEK7. Corrections welcome. What is genuinely missing is not the behavior — RHEL 9 and 10 both document the rule plainly — but its origin: no distro doc I found says the rule comes from a patch mainline declined, and the security exposure that follows is my analysis, not anyone's published guidance. I boot-tested both directions with a negative control. Once the keys are mine and shim leaves, this becomes load-bearing, so I filed a systemd RFE for a UKI section that enrolls module-signing keys, .mokkeys, and built it. It wrote shim's MOK entries from the boot stub, and three maintainers told me why that was the wrong place: the table's GUID is Linux's but the entry names inside it are shim's, and mainline wants an owner's consent signal, which an image verified by db cannot supply. I withdrew it in September. What I kept is on backup face B6: both kernel-side answers built on one tree, the .platform opt-in and the .vendor keyring, and what each one trusts.

11THE LADDER

Four rungs, and what each one costs.

/etc and /var stay writable by design at every rung: the scoped, auditable mutable surface · at rung 4 a recovery passphrase always works.

Where to stop is a requirements question.

The whole talk as one ladder, bottom up. Rung one, stock: the distro's signed boot plus a CI boot gate; that alone is public today and most shops would gain from stopping here. Rung two, sealed: one digest over the whole image, kernel-verified reads; costs UKI and composefs plumbing. Rung three, own keys: my PK and KEK replace the firmware's, my certificate goes into db, and what actually leaves is shim and MOK. Be exact here, because the honest claim is narrower than it sounds and someone will ask. On my metal, db trusts my one certificate AND four of Microsoft's, five in total, so the truthful statement is that the only loader on the disk is mine, not that the firmware would refuse theirs; a Microsoft-signed loader would boot, and that is the price of keeping the option ROMs working. Nothing was pruned. The one place a db really does hold only my certificates is the CI gate VM, which mints throwaway keys and enrols my certificate and nothing else, so the gate is stricter than the metal it gates. Costs a real key ceremony and the obligation to keep keys safe. Rung four, state-bound: the disk follows the signed boot, wrong OS means no disk, recovery passphrase always works; costs TPM enrollment and an actually rehearsed recovery drill. At every rung /etc and /var stay writable by design. Where to stop is a requirements question.

12CLOSE

What I found along the way.

systemdTPM2 unseal failed on ECC P-384 TPMs; fix zero-pads ECC point coordinatesmerged 08/2026 https://github.com/systemd/systemd/pull/43396

systemdRFE: .mokkeys module-signing key enrollment; withdrawn after review, the reasons in one commentwithdrawn 09/2026 https://github.com/systemd/systemd/pull/43638#issuecomment-5611922484

bootccomposefs fails with Docker v2s2 media typesopen https://github.com/bootc-dev/bootc/issues/1703

bootcinstall to-disk with LUKS + TPM brokenopen https://github.com/bootc-dev/bootc/issues/421

image-builderLUKS partition type in disk customizationsopen https://github.com/osbuild/image-builder/issues/2609

bootc · composefschunkah re-chunking regressions, filed at backout; four of my fixes merged, two reports openfiled · 4 merged https://github.com/bootc-dev/bootc/issues/2408 · https://github.com/composefs/composefs-rs/issues/383

the estate:https://gitlab.com/dunn.dev/cairn

the docs:https://cairn.dunn.dev

The two-box grammar and the sealing frame are borrowed with thanks from Mark Russell and Colin Walters of Red Hat, "Trust at every layer: how sealed images extend OS integrity from boot to runtime," May 2026:

https://www.redhat.com/en/blog/how-sealed-images-red-hat-enterprise-linux-extend-os-integrity-boot-runtime

A homelab at this depth trips over real edges, and the estate files what it finds: the P-384 fix means state-bound disks now work on ECC P-384 TPMs for everyone, merged in August; the .mokkeys RFE I withdrew in September after the maintainers showed me it wrote into shim's namespace, with the fixes I made to the successor branch public on my fork; two bootc findings and an image-builder question are open; the re-chunking regressions were filed when I backed that mechanism out, and the maintainer has merged four of my fixes, the last of them in September. Everything in the maintainers' own threads first, on their terms. Everything shown tonight is public: the estate and the docs are both linked, and anyone can fork it and swap in their own keys. Credit where the idiom came from: Russell and Walters, whose Red Hat blog post is linked there — read it, it is short and it is the clearest statement of the sealing frame. Thank you; questions. Backup faces follow for hallway questions.

B1BACKUPUPDATES OVER A CONSTRAINED LINK

What re-chunking saved on the wire.

How it ended

chunkah (coreos/chunkah) did not survive production use in this estate
I backed it out and filed the regressions to bootc and composefs
These are historical measurements, not live claims

Why it still matters

Content-keyed layering is the right shape for narrow links
The seal is unaffected: the root digest is computed over content, not transport layers

I measured it, then backed the tool out. Four of the fixes are merged.

For the forward-operating-base question: a full image pull was 1084 MiB; with the image re-grouped into 64 content-keyed layers, a median real day moved 585 MiB, 46 percent less; a controlled one-package update moved 87 percent less, and the gap between those numbers is my own driver blobs re-pulling, which is the boundary of the win. The ending: the re-chunking tool did not survive production use here, I backed it out and filed the regressions upstream. The measurements stand as measurements; the mechanism is theirs to mature. Since the backout the thread has moved: the multi-frame decoder fix (composefs-rs 381) and the docs fix (bootc 2409) merged August 25, the integration test (composefs-rs 384) merged August 26, all three applied by the maintainer. The fourth, error attribution on the failing blob (composefs-rs 382), merged September 10 after I rebased it. The two underlying reports stay open, bootc 2408 and composefs-rs 383. So: four merged, two open. And the seal never cared: the root digest is computed over content, not over how transport layers are arranged.

B2BACKUPTHE DISK GETS AN OPINION

I bound the disk to the boot I signed.

The boot state I signed

TPM checks the measured, signed boot
Releases the disk key
No passphrase typed, ever
A signed update unlocks without ceremony

One image, no per-machine ceremony

Anything else

No signature authorises this boot state
The unlock is declined before the TPM is asked
Disk stays sealed
Recovery passphrase always works

Refusal is the default; recovery is the exit

systemd-cryptenroll binds the LUKS slot to the signed boot measurement first boot re-binds that slot to the machine the image actually landed on on ECC P-384 TPMs this did not work until a fix of mine landed in systemd, 08/2026 the refusal is systemd's, before the TPM is asked: no signed policy for this boot's PCRs, no unseal attempt a replayed signature and a foreign policy key are indistinguishable from the console

one image, three install postures: TPM auto-unlock + recovery (edge) · passphrase only (attended) · no encryption (ephemeral, CI)

I demonstrated both directions on a real rig.

Rung four in detail: systemd-cryptenroll binds the LUKS slot to the TPM against the signed measurement, plus a recovery passphrase that always works. First boot re-binds the slot to the machine the image lands on. Demonstrated both directions on a real rig, 2026-08-29: a signed update unlocks with no passphrase typed — including one where a kernel argument changed, because the recipe re-signs the policy, which is the design working; and a post-signing tamper, where the .cmdline was altered but the old signature replayed, is refused with recovery the only way in. Be precise about the mechanism if asked: the TPM is never asked to unseal. The guest-to-TPM conversation stops after PolicyPCR, and systemd-cryptsetup declines in userspace because no signature in the image authorises the PCR11 the machine actually measured. Two causes land here and are byte-for-byte identical from the console: a replayed signature and a foreign policy key. If someone asks about a foreign OS, be careful, because the tempting answer is wrong. Under my own db, an image trusted by neither a certificate nor a hash is refused at LoadImage() and never executes, so the boot never reaches this question — but that is a property of MY db, not of the OS's origin. A mainstream distro's shim chains to a Microsoft third-party UEFI CA that OEMs commonly ship in db, and it would boot normally. Two more precisions if pressed: db can authorise by hash as well as by signer, so an unsigned binary can be allowed; and under shim the firmware only ever validates shim, after which trust delegates to a distro CA and an owner-controlled MOK list that no db knows about. Owning db, not the OS's provenance, is the control I am asserting. Do not quote the OVMF console string on stage as what Secure Boot says: BdsDxe's "Access Denied -- rejected probably by Secure Boot" is emitted by OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c, is OVMF-specific, will not appear on vendor firmware, and is EDK2's default policy for ANY validation failure — my own lab matrix has an unsigned image and a wrong-key image producing that identical line. One image serves three install postures: TPM auto-unlock with recovery for edge boxes, passphrase-only for attended installs, no encryption for ephemeral and CI machines.

B3BACKUPFIELD NOTE

A green gate that proved nothing.

WHAT I HAD ●

A lane that never ran

One path of the gate had never executed. Its checkmark was green anyway.

WHAT THAT MEANS ◍

An assertion that could not fail

Structurally green, whatever the artifact. Green was telling us nothing.

THE FIX ◆

Prove the gate can fail

Hand it a known-bad artifact and require a red result before trusting a green one.

the fix, rendered as a test

hand the gate a known-bad artifact .......... red · as required

the gate has now been seen red

I decide what a gate must prove, then break that exact thing on purpose.

B4BACKUPFIELD NOTE

What the build committed that I did not write.

WHAT HAPPENED

A stale boot ID rode into the image

A leftover /run/libpod file from the build container was committed into the OS image and surfaced at first boot.

WHY

Two builders, two commit semantics

rpm-ostree compose snapshots a clean tree; buildah RUN commits the container's runtime residue too. Same Containerfile, different bytes.

THE CHOICE

Compose semantics, deliberately

This estate builds rpm-ostree compose from scratch: a curated tree is snapshotted, so build-container residue never rides along.

rpm-ostree compose rootfs ...... a snapshot of the tree I curated

buildah build · RUN dnf … ......... that tree, plus what the run left in /run

the checklist line I took from this: pin the base by digest · know the builder's commit semantics

my choice is on the record as D1:https://gitlab.com/dunn.dev/cairn/base/-/blob/main/docs/decisions.md

Layering on someone else's base inherits its builder's commit semantics.

B5BACKUPDAY 2 · ROLLBACK

I gave the host a way to roll itself back.

THE SUCCESS BAR ⚑

boot-complete.target

The boot either reaches it or it does not. systemd-native, no agent.

THE MEMORY #

A machine-local counter

Failures accumulate across boots. The machine remembers its own bad mornings.

THE ACTION ↩

bootc rollback

The counter trips it; the previous image boots. No operator on the console.

runs on a live host in the estate · one deliberate failed-update rollback demonstrated

why I built my own · greenboot-rs is still GRUB2/grubenv-coupled; systemd-boot is an open RFE there:

https://github.com/fedora-iot/greenboot-rs/issues/175

and bootc's own maintainer named boot counting as wanted for the composefs backend:

https://github.com/bootc-dev/bootc/issues/1190

I maintain this gate myself. The maintainers have named the gap upstream.

Day 2 in one face: a small systemd-native health gate. boot-complete.target is the success bar, a machine-local counter accumulates failures across boots, and bootc rollback is the action when the counter trips; the previous image boots with nobody on the console. It runs on a live host in the estate and I demonstrated one deliberate failed-update rollback in the lab. Scoped to what I can actually show: greenboot-rs is still coupled to GRUB2 and grubenv, with systemd-boot support sitting as an open RFE and no mention of composefs anywhere in that repo either way; separately, bootc's own maintainer named boot counting as something the composefs backend would want, in a design thread that has since been closed. So this gate is a stopgap I own, and the gap is one the maintainers themselves have named. If someone asks whether greenboot-rs supports composefs, we do not know: we found nothing on it.

B6BACKUPTHE WRONG KEYRING

I put a key in the wrong keyring.

WHAT I TRIED §

.mokkeys

A UKI section; the boot stub wrote shim's MOK table from it, no shim present. It worked in the VM.

WHAT IT COST ✗

A week and three maintainers

The table's GUID is Linux's; the entry names are shim's. I had written under shim's names without asking.

WHAT I FOUND AT HOME ⌂

.machine is empty

My design record said a CA-shaped db certificate is promoted into .machine. It never is. Modules load through Fedora's db patch.

.platform OPT-IN · BUILT · +75 LINES

Trust db for module signatures only when the signed command line says so. .secondary untouched. Wart: root can kexec the token onto a stock kernel.

.vendor AS WRITTEN · BUILT · +275 LINES

A new table, any loader may fill it, linked into .secondary unconditionally: modules, kexec, IMA, vouching. No consent step. Parsed with Secure Boot off.

the withdrawal, in one comment:https://github.com/systemd/systemd/pull/43638#issuecomment-5611922484

six fixes to the .vendor branch, public:https://github.com/andrewdunndev/linux/tree/vendor_keyring-fixes

Both worked in my VM. I have filed neither.

The hallway version of the sidequest's ending. I wanted my own module-signing key trusted on a machine with no shim, so I built the .mokkeys section from systemd's own TODO: the boot stub wrote the MOK configuration table itself, under the entry names shim uses, and the kernel put my certificate in .machine and loaded my module. It worked, and it was in the wrong place. The table's GUID belongs to Linux, but MokListRT and MokListTrustedRT are shim's names, and the second one is a consent signal: the owner enrolled this key on purpose. An image verified by db cannot honestly say that. Lennart's suggested fix, extend shim's table if one is already installed, has no mechanism: InstallConfigurationTable replaces the pointer for an existing GUID and the kernel reads one table. I withdrew the PR, the issue and the spec change in September with one comment, linked here. On the way back I built both kernel-side answers on one tree with controls. The .platform opt-in, the 2025 RFC's idea with a gate, confines the new trust to module signatures and leaves .secondary holding only .builtin; its wart is that kexec_file_load takes its own command line, so root on a stock distribution kernel could add the token. Adrian Vovk's .vendor keyring, as written, nests inside .secondary, so one key ends up trusted for modules, kexec, IMA and vouching for further keys; it has no consent step and is parsed with Secure Boot off; it needed six small fixes to compile and boot, and those are public on my fork. And at home the wrong turn found a wrong sentence: my design record said a CA-shaped db certificate is promoted into .machine on the sealed stack; measured, it never is; .machine is empty on every host and modules load through Fedora's downstream db patch, and for no other reason. I have filed neither kernel patch. If anyone here works on the integrity side, I would like to know where that conversation belongs.

B7BACKUPTHE REAL RUN

What the pipeline actually did.

preflight ✓preflight-alignment

lint ✓reference-check ✓lint

base ✓build-base

modules ✓kmod-zfs ✓kmod-nvidia

layers ✓build-base-zfs ✓build-base-zfs-nvidia

validate ✓promote-base ✓manifest-gate

seal ✓promote ✓seal ✓sealed-boot ✓pcr11-anchor-gate ✓autoenroll ✓promote-sealed

cascade ✓trigger-instances

cairn/base main, 10 September 2026 · every pill links that job's log · the boot gate is sealed-boot, the disk binding is autoenroll, and promote-sealed is where the tag moves

the run:https://gitlab.com/dunn.dev/cairn/base/-/pipelines/2836618446

This is the run the rest of the deck describes.

B8BACKUPIPE · THE OPEN QUESTION

Why I still sign my modules.

WHAT I MEASURED · STOCK FEDORA 44

ipe is already an active security module, kernel modules are in scope, and a policy has to be signed by a key the firmware already trusts — which mine is. It ships switched off, with no policy loaded.

WHAT THE IPE AUTHOR TOLD ME · 14 SEP

The anchor he plans for composefs is a signed dm-verity backing store, and my ext4 lock buys fs-verity, not that. Where kmod decompresses in userspace it hands over a buffer, and IPE denies it. An RFC is coming.

I asked on Walters' tracker; Wu answered:https://github.com/composefs/composefs/issues/360

Module signing stays for now.

The face for a kernel person, and the one place this talk admits a cost it cannot yet remove. Everything else in the deck hangs off a single digest baked in at day 0 and enforced at read time. Module loading is the exception: nothing in that path consults the composefs digest, so I sign every module with the key that already signs the boot and turn on signature enforcement, and that signature requirement is the reason faces 09 and 10 exist at all. Integrity Policy Enforcement is the kernel's answer to that shape of problem: an LSM that decides whether a file may execute or load from a property of where the file came from, rather than from a signature attached to the file. Mark Russell put it to me in September as: once IPE can be wired to the composefs digest, signing kernel modules becomes unnecessary. That is the right question, so I went and measured what it would take, on a throwaway Fedora 44 box, kernel 7.2.4, and then I asked on the tracker. What I measured. IPE is compiled in and active on a stock cloud image, no custom kernel, which surprised me. It ships inert: the built-in boot policy is the empty string, no policy is loaded, and an unsigned runtime policy is refused before it is even parsed. The door is the platform keyring, so a policy signed by a key in UEFI db qualifies, and my signing certificate, the one that signs the UKI, is already there. Module loads on that rig arrived with a file descriptor, finit_module with MODULE_INIT_COMPRESSED_FILE, even though Fedora ships modules xz-compressed. And the composefs image ID, the fs-verity digest of the image file and the string in the mount source are all one value, which is the value day 0 already signs. What the author said, and this is the part that matters. Fan Wu, who wrote IPE, replied the same day. op=KMODULE does work for signed modules, though the existing ephemeral kernel signature check may need turning off for out-of-tree ones. My finit_module result is not general: where kmod decompresses in userspace it passes a buffer instead of a file, and IPE blocks that load outright, because a buffer has no provenance. verity=require is required configuration, but the trust originates in the erofs backing file. And FS_VERITY_BUILTIN_SIGNATURES is, in his words, not really necessary, because he plans to support only the dm-verity signature for composefs: likely the backing file has to come from a signed dm-verity. An RFC was expected within the week. So be careful with the conclusion. My ext4 lock buys fs-verity, which is what sealed composefs needs and what XFS cannot do; it does not give me dm-verity, which sits beneath the filesystem. And bootc cannot install one: BlockSetup in crates/lib/src/install/baseline.rs has exactly two variants, Direct and Tpm2Luks. So the mechanism that would retire module signing altogether is real, it is being actively designed by the person who wrote the subsystem, and as described it does not yet reach a bootc-installed disk. I would not claim more than that. Scope it honestly if pressed: I have shown bootc has no dm-verity install path, not that composefs on dm-verity is impossible by other means — an image built with mkosi and its own installer could present one, and confidential-os-builder, whose IPE policy first looked to me like the model, is mkosi on Ubuntu, not bootc. If anyone in this room works on IPE or on composefs, the question I would most like answered is which store a KMODULE rule ends up naming.