build: add rpm + gnupg (Fedora RPM GPG verification)#10
Merged
Conversation
Needed so the UKI build can verify Fedora package GPG signatures (rpm/rpmkeys + gnupg). Image parity: Dockerfile.build is kept byte-identical with stage1, whose tools/build-uki now GPG-verifies the kernel + systemd-boot RPMs it downloads. No effect on compiled artifacts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the docker-images + DOCKER_RUN plumbing block out of the Makefile into a canonical build.mk that the Makefile now includes. This is the source of truth for the shared harness, vendored byte-identically into stage1/vaportpm via the workspace make sync-harness and guarded by make check-harness. Pure relocation -- make -n expands identically; docker-build-harness (stage0-only) stays in the Makefile. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Both stage0 crates floated on vaportpm main (no rev), and stage0's Cargo.lock is untracked, so vaportpm-attest resolved to main HEAD on every build -- no version stability for a measured bootloader. Pin to the v0.3.0 release commit (7041f461) with a version = "=0.3.0" guard, keeping default-features = false (no_std core: Tpm, PcrOps, TpmTransport). Verified: stage0.efi and payload.efi build clean for x86_64-unknown-uefi against v0.3.0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
HarryR
force-pushed
the
fedora44-kernel-bump
branch
from
fcda1b0 to
9e64f6e
Compare
…entifiable)
Replace the stage0.efi-hash-derived DISK_GUID/PART_GUID/VOLUME_ID with fixed
constants ("4c4f434b424f4f54" spells "LOCKBOOT"; last group a role index:
disk = 0, ESP = partition 1). Constant across releases so the GPT -- and hence
the firmware's PCR 5 measurement -- is byte-stable, and a lockboot disk is
identifiable by GUID. Dependency of stage2, which locates the boot disk by GUID
and rewrites the GPT to add its runtime/data partitions; a stable base GPT keeps
PCR 5 predictable. The stage0.efi hash still feeds BUILD_ID.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
HarryR
added a commit
to lockboot/stage1
that referenced
this pull request
Jul 13, 2026
…#19) ## What Bring the UKI to a current, GPG-verified Fedora 44 base, bundle the kernel modules stage2 needs, and supporting build cleanups. ## Kernel + stub - Bump kernel `6.12.4-200.fc41` -> `7.0.12-201.fc44` and systemd-boot stub `256.17-1.fc41` -> `259.6-1.fc44` (what Fedora CoreOS 44.20260621.3.1 ships). `fc41` is EOL; the kernel was ~18 months behind. - **GPG verification (mandatory):** `download-verify-rpm.sh` fetches from koji's *signed* path (plain `packages/` is unsigned) and verifies each RPM against `keys/RPM-GPG-KEY-fedora-44-primary` (fp `36F6 12DC F27F 7D1A 48A8 35E4 DBFC F71C 6D9F 90A6`) on every build. - **Automated bumps:** pins live in generated `tools/build-uki/fedora-deps.mk`; `make update-fedora-deps FCOS=... SYSTEMD=...` reads the FCOS manifest, downloads + GPG-verifies the signed RPMs, and rewrites the pins. ## Storage modules for stage2 - Bundle + explicitly load (in dependency order, before the `modules_disabled` latch) the modules stage2's loader needs: **dm-crypt** (encrypted /data), **dm-verity** + **reed_solomon** (integrity-checked erofs runtime + FEC dep), **overlay** (ephemeral root), **erofs** + **netfs** (RO image fs + dep), and the **nvme** chain (hkdf -> nvme-auth/keyring -> nvme-core -> nvme; EC2 EBS + the harness disk are NVMe). The payload cannot load modules itself, and an unresolved dep can't be pulled once the latch is set, so deps are listed explicitly. - Module comments describe each dependency's capability generically. **Authenticated /data (dm-integrity + async_xor/async_tx) is documented as an extension point but not shipped** -- stage2 uses confidentiality-only dm-crypt, so those are omitted to keep the measured initramfs minimal. ## Build - Pin `vaportpm-attest` to v0.3.0 (rev + version guard). - Extract the shared `DOCKER_RUN` harness into `build.mk`. - Drop a stale `kernel-hash-%` target. ## Verification - ena (AWS) + gve (GCP) present in 7.0.12; all required `.ko.xz` copy. - `make test-chain-x86_64 SIGN=1 / MANIFEST=1 / SIGN_ARGS=1` boot `Linux 7.0.12-201.fc44` end to end and run stage2. - lockboot/stage2's XTS pivot test passes end to end on this UKI (`PIVOT_TEST=PASS`), dm-integrity absent from the boot. - aarch64 pins are GPG-verified but not boot-tested here. Pairs with lockboot/stage0#10 (image parity: rpm+gnupg, shared harness, vaportpm pin, stable GUIDs). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Bring the stage0 build image and disk layout in line with the Fedora 44 chain bump, plus stable disk identity.
Changes
Dockerfile.buildso the UKI build can verify Fedora package GPG signatures (image parity with stage1, kept byte-identical). No effect on compiled artifacts.DISK_GUID/PART_GUIDare now constant across releases (4c4f434b-424f-4f54-..., "LOCKBOOT" + a role index), so the initial GPT is byte-stable (stable pre-stage2 PCR5) and the boot disk is identifiable by a fixed GUID rather than by hashing stage0.efi (which changed per release). This is the stable identity stage2'sfind_boot_devicecan key on. (stage2 still rewrites the GPT at runtime to add p2/p3, which is why it excludes PCR5 from its key binding.)vaportpm-attestto v0.3.0 (rev + version guard), matching stage1.DOCKER_RUNharness intobuild.mk(same refactor as stage1).Verification
🤖 Generated with Claude Code