Description
The System Boot and Security Microconference remains a key venue for engineers and researchers focused on the intersection of firmware, bootloaders, and kernel security. For 2026, we continue our mission to address the persistent friction encountered when upstreaming security-focused boot improvements. Our goal is to bridge the gap between low-level hardware initialization and the Linux kernel requirements.
Experience shows that integrating complex security technologies - like TrenchBoot or advanced attestation frameworks - often stalls due to architectural disagreements or a lack of cross-project coordination. We want to bring together developers from different layers of the stack (firmware, bootloaders, and kernel) to identify these bottlenecks.
We are interested in deep technical deep-dives, but also in the legal, licensing, and organizational aspects that often dictate how-and if-security standards can be integrated into the open-source ecosystem.
We invite proposals covering technical updates, work-in-progress, and strategic discussions on:
- TrenchBoot, tboot,
- TPMs, HSMs, secure elements,
- Roots of Trust: SRTM and DRTM,
- Intel TXT, SGX, TDX,
- AMD SKINIT, SEV,
- ARM DRTM,
- Growing Attestation ecosystem,
- IMA,
- TianoCore EDK II (UEFI), SeaBIOS, coreboot, U-Boot, LinuxBoot, hostboot,
- Measured Boot, Verified Boot, UEFI Secure Boot, UEFI Secure Boot Advanced Targeting (SBAT),
- shim,
- boot loaders: GRUB, systemd-boot/sd-boot, network boot, PXE, iPXE,
- UKI,
- u-root,
- OpenBMC, u-bmc,
- legal, organizational, and other similar issues relevant to people interested in system boot and security.
Progress in various areas after LPC 2025:
CVE (CVE-2026-33697) of score 7.8/10 discovered and responsibly disclosed
Security advisory
Presentations, Slides, Videos etc. after LPC'25
-
Who Authenticates Linux? Rethinking PAM & NSS in the Age of Cloud Identity
-
TrenchBoot Linux Kernel Developments
- Android Boot, DRTM, UKIs As an alternative solution to DRTM for ARM Mobile systems, Android's Virtualization team has delivered an EL2 stub
-
Nandakumar Raghavan
Linux has no standard model for provisioning and unlocking encrypted persistent storage at boot in environments where the underlying platform cannot be fully trusted. Today, every deployment stack solves this independently: custom boot agents, post-provisioning scripts, and platform-specific unlock logic. The mechanism exists โ LUKS2 tokens and the cryptsetup plugin interface โ but the...
Go to contribution page -
Hongming Qiu (University of Illinois Urbana-Champaign)
eBPF programs enter the kernel as privileged extensions and, once admitted, become part of the systemโs trusted computing base. Prior LPC discussions established BPF signing as a way to track the provenance of these programs, while deliberately separating signature verification from the policy that consumes it [1,2]. IMA was identified as one possible consumer through LSM integration, but its...
Go to contribution page -
Yi-Yo Chiang (Google)
Android is evaluating the Linux EFI boot stub to standardize OS handoff and reduce bootloader feature duplication. We examine the architectural blockers that arise when dealing with strict embedded hardware constraints, aiming to brainstorm solutions.
Topics for Discussion:
-
EL2 Elevation and KVM within an EFI context
- The Problem: KVM requires booting the kernel at EL2....
-
-
Anushka Nabar (Qualcomm)
ARM SystemReady defines a standard firmware-to-OS boot path via UEFI, but provides no standard mechanism for booting Type 1 hypervisors such as Gunyah or Xen. Platforms relying on Type 1 hypervisors to isolate security- or latency-sensitive workloads, lack a standardized boot flow, which creates fragmentation across mobile, IoT, and compute ecosystems.
We have implemented a solution for...
Go to contribution page -
Muhammad Usama Sardar (TU Dresden)
Abstract:
Go to contribution page
This talk is a follow-up of LPC'25, where we introduced the security problem to the community for the suitable approach of attested TLS protocols. We have defended our position (cf. [expat BoF][1]) to standardize the attested TLS protocol in the [IETF][2], and a new Working Group named [Secure Evidence and Attestation Transport (SEAT)][3] has been formed to exclusively tackle... -
Ignat Korchagin (Citadel)
Linux Crypto API has recently come under fire due to a series of discovered vulnerabilities, like [Copy Fail][1] and friends. This resulted in a drastic response from some maintainers: deprecation of the [Linux Crypto API userspace interface][2]. However, it feels like cracking a nut with a sledgehammer, as some vulnerabilities, like [Dirty Frag][3], do not even use the userspace interface...
Go to contribution page -
Piotr Krรณl (3mdeb)
Arm's DRTM architecture (DEN 0113) defines a dynamic root of trust for measurement: a DCE-Preamble triggers a dynamic launch event, EL3 firmware (TF-A) measures a protected payload into a fresh chain of trust, and the dynamically launched measured environment (DLME) continues under a smaller TCB. Yet a working implementation exists only against the Base AEM FVP TF-A's plat_drtm hooks...
Go to contribution page -
Sherif Nagy
This talk walks through the end-to-end process for Linux distributions to have their SHIM submitted for review and eventual signing by Microsoft, surfacing the challenges faced by both distribution teams and the SHIM review team.
We examine this process in depth from dual vantage points: distribution maintainers navigating submission requirements -- including SBAT entries, CVE patching, DBX...
Go to contribution page