We just tagged lockboot v0.2.0 — here's what changed.

Dynamic VMA calculation

Previous releases hardcoded section virtual memory addresses when assembling the UKI. This worked fine with the systemd-boot stub from AL2023 (v252), where VMAs start low (~0x20000), but broke with newer stubs like Fedora 41's v256 where VMAs jump to ~0x14df90000.

v0.2.0 now parses the stub's PE sections with objdump and appends new sections after the last one — the same approach ukify uses. This means lockboot works correctly regardless of which systemd-boot stub version you supply.

aarch64 PE vmlinuz

The v252 stub on aarch64 would hang when handed a PE-format vmlinuz. With v256, the stub uses LoadImage/StartImage to boot PE kernels properly. lockboot v0.2.0 detects the kernel format and selects the right loading strategy automatically.

QEMU test harness

The qemu-test/boot.sh script now handles serial console differences across architectures:

• aarch64: The kernel auto-registers SPCR as a regular console, so PCI serial just works.
• x86_64: Needs an explicit console=ttyS0 parameter. We also switched from PCI serial (1b36:0002) to ISA serial for QEMU testing, since the 8250_pci driver in Fedora's kernel doesn't detect the QEMU PCI serial device. Real EC2 instances still use ttyS0 as expected.

What's next

• Azure support
• Measured boot policy enforcement
• Automated attestation integration with vaporTPM