Linux Security Summit Europe 2025

Microarchitectural attacks such as Branch History Injection (BHI) can expose kernel data when instructions at a mispredicted indirect call target are executed speculatively with malicious data crafted by the attacker.

FineIBT (Fine-grain Control-flow Enforcement with Indirect Branch Tracking) is a hardening technique adopted by the Linux kernel (first merged in 6.2) that performs a check at each indirect call target to ensure that the target’s type (e.g., void (*)(int)) matches the type of the function pointer that was used to make the call. Although FineIBT can provide substantial defense-in-depth against architectural attacks such as Call-Oriented Programming (COP), its current implementation does not address microarchitectural attacks.

This talk introduces a new enhancement to FineIBT that hardens the Linux kernel against a plethora of microarchitectural attacks—including BHI—by poisoning the contents of live registers whenever the FineIBT check fails, thus preventing an attacker from using those registers to pass malicious data to a mis-predicted call target. This enhancement has been merged into Linux 6.15.

Starting with Linux 6.14, we will be able to securely control script execution using new execveat(2) and prctl(2) flags, successors to O_MAYEXEC. This marks a crucial step toward fully supporting code integrity on Linux.

The next steps involve enlighting script interpreters and providing users with straightforward ways to incrementally enforce such restrictions. Options include leveraging existing LSM policies and configuring user-space process management services (e.g., systemd).

In this talk, we will explore the kernel changes that were required (e.g., uAPI, IMA, IPE) and the ongoing complementary user-space updates, including script enlightenment. We will also explain the rationale behind the new securebits and how they facilitate a smooth migration, especially for generic Linux distributions.

One of Landlock's main goals is to empower Linux users to sandbox their programs. We've focused on building the foundation of a new unprivileged access control system, including an interface for developers to sandbox programs. While sandboxing tools already leverage Landlock, a well-defined way to describe security policies is still needed.

To address this, we're designing a user-friendly configuration format, marking a significant step toward making Landlock more accessible. This format enables users to describe a set of restrictions enforced on their programs and helps democratize Linux sandboxing. The new configuration format and related library simplify sandbox creation by allowing users to compose modular security policies. Linux distributions can also provide predefined policies that users can customize, reducing the maintenance burden.

In this talk, we’ll explain the design of this new configuration format, available to end users via TOML and to developers via JSON. We'll also demonstrate a new tool that makes Landlock sandboxing straightforward and accessible.

CI/CD pipelines are complex environments. This complexity requires methodical comprehensive reviews to secure the entire stack. Often a company may lack the time, specialist security knowledge, and people needed to secure their CI/CD pipelines. Realising these facts; cyberattacks targeting CI/CD pipelines has been gaining momentum, and attackers increasingly understand that build pipelines are highly-privileged targets with a substantial attack surface. In this presentation, we will share some of our observation through showing different flavours of attack on possible development pipelines, and introduce a tool to detect them.

This talk presents a fully open-source framework to achieve secure full disk encryption (FDE) for TPM-equipped Edge devices (IoT), balancing strong security guarantees with practical maintainability at scale. We address key features including automated disk unlocking and recovery, monitoring and remote access. The talk will cover the following:

* A fully verified boot chain, from EFI firmware through the initramfs. We'll cover which system components to verify and common pitfalls to avoid when setting up a secure boot chain.
* A newly-developed, open-source TPM PCR prediction mechanism enabling seamless reboots after kernel or initramfs updates.
* Automated disk encryption key onboarding and recovery using Tang and Clevis.
* Secure remote access and fleet observability while disks remain locked - using WireGuard, SSH, and Prometheus.
* Guidance on how to extend the initramfs (dracut) with your own tooling.
* Discussion of shortfalls and potential security risks

Our aim with this talk is to help you make FDE convenient, recoverable and monitored to make large-scale rollouts possible.

Bootloaders are foundational to system security, yet their attack surface often remains under-scrutinized.
This talk presents ongoing efforts to harden the security posture of the barebox bootloader when used in verified boot chains.

Topics include defining the security-critical subset of the verified boot path, applying fuzzing to core logic, and highlighting the security implications of user configurations.
The session will also cover software hardening measures, mechanisms for secure runtime unlocking and the formalization of security issue handling.

Attendees will gain insight into both the technical challenges and the roadmap to help users deploy a verified boot chain into embedded products while minimizing potential risks.

There have been thousands security vulnerabilities in Linux OS community and also has new detected ones every day. The operating system vendors (OSVs) have to take big effort to mitigate CVEs and hardening the OS. To save the effort, we analyzed most of the history CVEs in Linux kernel, and understand the CVE distribution by CWE, kernel config, sysctl parameters and others key attribution. In this way, we expect to understand which OS hardening method is most useful and which is not so important. Furthermore, we also expect it can help us prioritize the CVEs, then we only need focus on the most critical one. Last, we also prefer to share how we handle the CVEs in the production Linux kernel and expect it can benefit more talent in Linux community.