[patrislav]

Today the build is a shell script driving two binaries we do not own: a downloaded linuxkit release, used purely as a YAML-driven cpio packer, and AWS's eif_build example, compiled from a pinned commit against a vendored lock file. Three moving parts, none of them ours, to turn a layout file into an image. This replaces all of it with one program in this repo that we can read, test and change.

First of three stacked pull requests. The enclave's contents do not change here, so the only PCR movement comes from cpio and gzip byte differences against LinuxKit's encoder.

What lands

• A Cargo workspace at the repository root with a committed lock file, a pinned toolchain and release settings chosen for reproducibility, so the enclave binary added later inherits them.
• eiffel-build: a CLI, a layout parser, a hand-written newc cpio writer, gzip with a zeroed header timestamp, and image assembly through aws-nitro-enclaves-image-format. It forbids unsafe code.
• The layout parser accepts only the LinuxKit files: subset our two layouts actually use and rejects everything else, so a layout carrying init: or onboot: fails loudly instead of quietly producing an empty ramdisk. It also rejects absolute paths, .., empty segments, duplicates and ambiguous entries, and creates missing parent directories the way the kernel's unpacker requires.
• The bootstrap ramdisk is added before the customer one. PCR1 covers the first ramdisk, so that order is a correctness requirement rather than a style choice.
• A new output alongside the image, holding the measured PCR values as JSON. This is what attestation policies should pin.
• The shell script and the vendored lock file are deleted. The Dockerfile gains a pinned builder stage and a slim final stage. The kernel stage splits in two so that later work needing only the unpacked source tree does not have to compile a kernel; the compile itself is unchanged.
• Two workflows. Pull requests run formatting, lints and tests only. The image build, the end-to-end example build and the reproducibility double-build run on master, on tags and on manual dispatch, so no pull request compiles a kernel.

The published image keeps its contract: same entrypoint behaviour, same blob, config, workspace and output paths, so existing customer builds work unchanged.

Verification

• Formatting, clippy with warnings denied, and the test suite all pass. Nine tests: schema rejection cases, a cpio header golden test, a byte-for-byte determinism test and padding checks.
• The cpio golden test was generated with GNU cpio in a container, since the macOS cpio is bsdcpio and rejects the reproducible flag. Two deviations from GNU's output are documented in the test: the mtime is zeroed and inodes are numbered from one.
• Generated archives pass gzip -t, and listing them shows exactly the entries and modes the layouts call for, with zero ownership.
• Two runs over the same inputs produce identical PCR output. The image itself differs only in an unmeasured build-time field.
• Error paths leave no partial image behind: the output is written to a temp file and renamed on success.
• The builder stage and the final stage were each built under emulation and the binary was exercised inside the final image.

An extra dependency

serde_json, beyond the small set this crate otherwise needs. The image-format crate types two of its metadata fields as JSON values, so the struct cannot be constructed without naming the crate. It was already in the tree transitively, and it also serialises the PCR output.

Not verified

The full image was never assembled, since the kernel stage takes eight minutes under emulation on the machine this was built on. No image was booted, on Nitro hardware or otherwise, and no PCR value was compared against a running enclave. The QEMU boot test is written but has never had a chance to run.

Impact

PCR0, PCR1 and PCR2 all move. Consumers must re-pin from the new PCR output.

🤖 Generated with Claude Code