Linux Security Summit North America 2026

The Lockdown LSM is intended to ensure the integrity of all code in kernel space. Hibernation is a technology that allows the entire contents of RAM to be stored to disk and then later restored. What stops an attacker modifying the contents of the hibernation image, or providing their own hibernation image that contains malicious code, violating the design goals of Lockdown? The answer at the moment is "Lockdown disables hibernation", and everyone agrees that this is a bad answer. Let's fix that.

This presentation will describe the design and implementation of a patchset that allows hibernation images to be secured using hardware-backed keys, tied to system state in a way that prevents them being extracted and used to sign a malicious image. It will cover some of the corner cases and describe future work that would enable additional behavioural guarantees that are not part of the initial implementation. We will then discuss whether this is the right way of solving the problem, what alternatives there might be, and whether any of this is worth t at all.

Linux containers rely on namespaces, capabilities, and seccomp profiles to enforce isolation. However, several powerful debugging and observability interfaces remain accessible in many deployments and are rarely audited from a security perspective.

This talk explores how Linux debugging mechanisms such as ptrace, perf, and tracing interfaces interact with container isolation boundaries. While these tools are designed for diagnostics and performance analysis, misconfigured access to them can expose unexpected attack surfaces that enable information leakage, privilege escalation, or container escape.

Through practical demonstrations, we examine how these interfaces can be abused in real environments and why many monitoring tools unintentionally weaken isolation guarantees. The session also presents practical hardening strategies, including capability minimization, runtime policy enforcement, and safer observability deployments for production systems.

As computing systems evolve, memory-safety exploits such as return-oriented programming (ROP) and jump-oriented programming (JOP) remain a serious threat. These attacks manipulate control flow within valid address space, reusing existing code “gadgets” to achieve the attackers desired results. Arm AArch64 provides architectural defenses against these attacks through Pointer Authentication Codes (PAC), Guarded Control Stack (GCS), and Branch Target Identification (BTI).

This talk explains how these technologies work and, more importantly, what Linux developers, distributions, packagers, and toolchains must do to deploy them correctly. We cover the AArch64 Linux ABI implications, including requirements for hand-written assembly, use of BTI and PAC instructions, and PAC key management. We dive into real-world toolchain and language impacts, including changes to C code generation, C++ exception unwinding, DWARF metadata updates, and use of Arm's hint space instructions. Attendees will also learn common pitfalls, debugging challenges, and deployment trade-offs observed in practice.

By the end of this session, participants will understand how to deploy PAC, GCS, and BTI across Linux.

Intel Control-Flow Enforcement Technology (CET) represents a milestone in hardware-assisted exploit mitigation, providing silicon-level defenses against Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP). This session provides a deep-dive analysis of the two pillars of CET—Indirect Branch Tracking (IBT) and Shadow Stacks (SHSTK)—and their integration into the Linux kernel.

We trace the implementation journey from the initial merge of IBT in Linux 5.18 to the arrival of userspace Shadow Stacks in Linux 6.6. The session explores the microarchitectural mechanics of the #CP (Control Protection) fault and how the kernel manages shadow stack allocations, signal frame tokens, and context switching.

Key topics include:

Forward-Edge Integrity: How IBT uses the ENDBR opcode to restrict indirect branch targets.

Backward-Edge Defense: A deep look at hardware-enforced Shadow Stacks and the management of the Shadow Stack Pointer (SSP).

The Kernel Interface: Leveraging arch_prctl(2) for application opt-in and the role of GLIBC_TUNABLES in production environments.

Edge Cases: Handling complex control flows like setjmp/longjmp, JIT engines, and signal restorers.

Most Linux distributions trust individual maintainers with complete package control, creating critical supply chain vulnerabilities. StageX rebuilds this trust model from scratch with a radically different approach: no single person or computer can compromise the system.
StageX requires fully bit-for-bit reproducible builds verified and signed by multiple independent parties before release. Built from 181 bytes of machine code, StageX bootstraps modern toolchains that can be used in container-native and static contexts.
This talk demonstrates StageX's approach to full-source bootstrapping, bit-for-bit reproducibility and multi-party verification; contrasts it with other reproducible build efforts like NixOS/Guix, and shows how its container-native design provides practical security guarantees. You'll learn how to implement these approaches in your own infrastructure to build software from toolchain to deployment.

The Linux kernel's cryptography framework has long been a source of frustration for developers. Its complex and abstract API is often a poor fit for modern algorithms and hardware. Using it correctly is quite difficult, and its performance is suboptimal due to the required dynamic memory allocations, indirect calls, and other API overhead.

This talk presents recent progress in supporting more algorithms via straightforward library APIs, including hash functions, MACs, and CRCs. We will explore how various kernel subsystems have been refactored to use these libraries, simplifying their code and improving performance.

Finally, I will also cover best practices for adding new kernel features that use cryptography, the adoption of modern practices in the crypto library such as KUnit testing, and new features in the crypto library such as support for the SHAKE extendable-output functions and ML-DSA post-quantum signatures.