A safety net for eBPF: adding KASAN support to JITed programs

The eBPF technology implemented in the Linux kernel keeps on gaining traction in various areas: infrastructure, observability, security, debugging, and many more. Its wider adoption reinforces one core concept that drives its development: it must be safe for the kernel to load an eBPF program, and so a program that cannot be proven to be safe must be rejected. This fundamental concept led to the development of some complex mechanisms such as the BPF verifier; but this guarantee is not foolproof: the verifier is written in C and can have the same kinds of bugs as the rest of the kernel. Addressing this kind of risk is a key strategy for Alpha-Omega, which is funding initiatives to improve the security and safety of widely used software projects and technologies. Alpha-Omega allocated a grant to the eBPF Foundation, which teamed up with Bootlin, to improve the security and safety of the eBPF technology by implementing KASAN support in eBPF programs, with the goal of enabling better detection of memory-safety issues for eBPF subsystem developers.

Continue reading “A safety net for eBPF: adding KASAN support to JITed programs”

Yocto Blacksail released, Bootlin contributions inside

Yocto ProjectYocto Blacksail 6.1 is now released. This is the new stable release of the Yocto Project and will be maintained until April 2027. Bootlin is a very active contributor to the Yocto Project, most notably with Antonin Godard being the official Yocto Project documentation maintainer, and Mathieu Dubois-Briand being a core member of the Yocto SWAT team, but also with other Bootlin engineers who use and deploy Yocto to create optimized and long-term maintainable Linux systems for the embedded devices of our customers. This 6.1 release was no exception, and we were again very active in this release cycle, with over 200 commits authored by Bootlin engineers.

Continue reading “Yocto Blacksail released, Bootlin contributions inside”

Rockchip SoCs: a foray into eFuse territory

Every System-on-Chip has a boot ROM taking care of finding the next component in the boot process, load and run it. Each different vendor tends to implement a different strategy for their boot ROM, often with similar capabilities.

We have written about the Rockchip SoCs boot ROM before on this blog, for instance to discuss their recovery boot capability and the related tooling.

This time, we’re going to look into a particular piece of memory on the SoC, that is very important to the security of the SoC: the secure eFuse.

Continue reading “Rockchip SoCs: a foray into eFuse territory”

Linux 7.3 released, Bootlin contributions inside

TuxLinus Torvalds has released the 7.3 kernel last Sunday afternoon. LWN once again covered extensively the content of this new version through two merge window posts (see part 1 and part 2). This release continues the record-breaking spree started a few releases ago, with 18,765 non-merge commits from 3,021 developers, with plenty of first-time kernel contributors. You can find more details and facts about this release in the 7.3 coverage from LWN.

Continue reading “Linux 7.3 released, Bootlin contributions inside”

Device tree addons: describing non-discoverable addon boards and connectors

Lots of embedded devices exist that have a connector for addon boards: BeagleBone Black Capes and Raspberry Pi Hats are just some common de facto standards, each with a whole ecosystem of base boards and addon boards that can be mixed and matched in countless ways. Most of them are based on embedded System-on-Chips, and thus use device tree to describe their hardware. Yet there is no good way to describe the connectors and addons in an efficient, modular and effective way.

At Bootlin we have been working for a few years to implement a proper way of describing such addon boards and their connectors using device tree. We have found a huge interest in the embedded systems community, but the road to get there is steep.

Our initial effort based on device tree overlays was rejected due to fundamental shortcomings in the device tree overlay design at its root. After discussing with the community we are now proposing a totally new concept: device tree addons. It’s a huge work, a lot has been done but there is still a lot to be done.

This post introduces the rationale and use cases, shows a practical example, describes how to test our current proposal and, last but not least, suggests how to contribute to the mailing list discussion to help this work land upstream for everyone’s benefit.

Continue reading “Device tree addons: describing non-discoverable addon boards and connectors”

Welcome to Thomas Païta and Paul Cercueil

We recently welcomed two engineers to our team: Thomas Païta, based at our Lyon office, and Paul Cercueil, working from Madrid, Spain.

Thomas Païta

Thomas PaïtaThomas joined Bootlin at the end of June 2026. After graduating from the Université de Technologie de Compiègne, he worked on embedded Linux and FreeRTOS at Sagemcom, followed by Rust and C++ development in the space industry. At Bootlin, his work will focus not only on Embedded Linux, but also on Zephyr.

Thomas is currently the 5th Thomas at Bootlin, joining Thomas Petazzoni, Thomas Perrot, Thomas Richard, and Thomas Bonnefille.

See his profile page for more details.

Paul Cercueil

Paul CercueilPaul joined Bootlin in September 2026. After graduating in 2014 from the Université de Technologie de Belfort-Montbéliard, Paul worked at Analog Devices, where he designed and developed the ecosystem around Linux’ IIO subsystem and authored the companion libiio project. In addition to his work on IIO, Paul has extensive Linux kernel experience, with over 750 patches, mainly focused on supporting MIPS-based Ingenic SoCs, for which he is the platform maintainer. Paul also has a solid background in Buildroot, having been the main developer and maintainer of the Buildroot-based OpenDingux distribution, as well as contributing more than 60 patches to upstream Buildroot. Paul also enjoys tinkering with other retro-gaming console projects, including the KallistiOS project, an operating system for the SEGA Dreamcast, and a MIPS-to-everything JIT compiler for the PlayStation 1.

Paul is French and also speaks English and Spanish fluently. See his profile page for more details.

audio-iio-aux: when IIO meets audio

Some time ago, one of our customers came to us with a hardware design featuring the Renesas X9250 digital potentiometer in an audio path, as shown in the following diagram. Naturally, our goal was to find the proper way to support this hardware design in the upstream Linux kernel.

Audio path with potentiometer

Since the X9250 is part of an audio path, the first thing that came to mind was the ALSA subsystem of the Linux kernel. However, the Renesas X9250 is a generic digital potentiometer, and audio is only one of its many possible use cases.

The Linux kernel also has a separate subsystem called IIO (Industrial I/O), which provides support for a wide range of devices, including accelerometers, various types of sensors, ADCs, DACs, and potentiometers. Potentiometers are already supported by IIO, as can be seen in the drivers/iio/potentiometer directory.

IIO is not specific to audio, so implementing the Renesas X9250 driver as an IIO driver made more sense than implementing an ALSA-specific driver. This way, the same driver can be reused for non-audio use cases as well.

However, we still needed a way for the potentiometer to be handled as a regular component of an audio path through the ALSA subsystem.

Continue reading “audio-iio-aux: when IIO meets audio”

Bootlin toolchains 2026.08 released

Bootlin toolchains 2026.08We are happy to announce the release of a new version of our freely available, pre-compiled cross-compilation toolchains, hosted at toolchains.bootlin.com.

This update covers a range of 43 CPU architecture variants, including: aarch64, aarch64be, arcle-750d, arcle-hs38, armv5-eabi, armv6-eabihf, armv7-eabihf, armebv7-eabihf, armv7m, m68k-68xxx, m68k-coldfire, microblazebe, microblazeel, mips32, mips32el, mips32r5el, mips32r6el, mips64-n32, mips64el-n32, mips64r6el-n32, openrisc, powerpc-440fp, powerpc-e300c3, powerpc-e500mc, powerpc64-e5500, powerpc64-e6500, powerpc64-power8, powerpc64le-power8, riscv32-ilp32d, riscv64-lp64d, s390x-z13, sh-sh4, sh-sh4aeb, sparc64, sparcv8, x86-64, x86-64-v2, x86-64-v3, x86-64-v4, x86-64-core-i7, x86-core2, x86-i686, xtensa-lx60.

As with previous releases, we provide two editions of each toolchain: a stable version based on the N-1 releases of GCC, binutils, GDB, and slightly older kernel headers, and a bleeding edge version featuring the latest available components. For the 2026.08 release, the versions are:

  • The bleeding-edge toolchains are based on gcc 16.2, binutils 2.46.1, gdb 17.1, kernel headers 6.12, glibc 2.44, musl 1.2.6 or uclibc-ng 1.0.59.
  • The stable toolchains are based on gcc 15.3, binutils 2.45.1, gdb 16.3, kernel headers 5.10, glibc 2.44, musl 1.2.6 or uclibc-ng 1.0.59.

All toolchains are built for x86-64 Linux hosts and are compatible even with relatively old Linux distributions. We welcome bug reports and feedback through our project issue tracker.

Bootlin’s Yocto training course updated to Wrynose

Yocto ProjectThe latest Long Term Support release of the Yocto Project, Yocto Project 6.0 (Wrynose), was released a few months ago, so it was time to update our Yocto Project training materials. This update is now complete.

As with every new Yocto Project release, Wrynose brings a number of changes and new features. Some of them affect the way developers work with Yocto, so we have updated our slides and labs accordingly. In particular:

  • The bitbake-setup tool was introduced as the Yocto Project-supported way to fetch layers and set up a build configuration. This has been a long-requested feature, and it is now covered in our training.
  • As part of this change, the Poky Git repository has been deprecated and is no longer maintained. Users now fetch the base components through a bitbake-setup configuration file or by using an external tool.
  • Support for configuration fragments was added, making it possible to group related and consistent configuration settings together. This is intended to simplify configuration management, whether or not bitbake-setup is being used. The new bitbake-config-build command can be used to enable these fragments from the command line.
  • There are also internal changes that affect how recipes should be written. These changes are reflected in our training materials. For example, the introduction of UNPACKDIR changes how the S and WORKDIR variables can be used.

Updated labs

We continue to support four different boards in our practical labs:

  • STM32MP157A-DK1
  • i.MX93 FRDM
  • BeaglePlay
  • BeagleBone Black

For each of these platforms, we use either vendor-provided or community-supported layers, each approach has its own advantages and limitations.

The labs have therefore been updated alongside the training slides to ensure that they remain aligned with the latest Yocto Project release.

Join our Yocto Project training

As with all Bootlin training courses, the Yocto Project training materials are freely available on our website.

If you would like to attend the training with an instructor, we offer public online sessions scheduled by Bootlin. We can also organize private online or private on-site sessions on demand.

Our next public sessions with available seats are:

Whether you are new to the Yocto Project or want to update your existing knowledge, our training provides both the concepts and hands-on experience needed to build and maintain embedded Linux systems with Yocto.

sbom-cve-check 1.3.2 and 1.3.3: improved SBOM handling and more robust CVE analysis

sbom-cve-checkSince our previous update on sbom-cve-check, the project has continued to evolve with two new releases: version 1.3.2, released in June, and version 1.3.3, released in August.

These releases bring a number of improvements to the handling of SBOM data, CVE version ranges and vulnerability assessments, as well as fixes for some corner cases encountered when analyzing real-world software projects.

For those discovering the project, sbom-cve-check is a lightweight open-source tool developed by Bootlin for performing vulnerability analysis on Software Bill of Materials (SBOMs). It is based on SPDX SBOMs and can be used both as a standalone tool and through its integration in the Yocto Project. Since the Yocto Project’s Wrynose release, sbom-cve-check has been used as the Yocto Project’s official tool for CVE monitoring.

Continue reading “sbom-cve-check 1.3.2 and 1.3.3: improved SBOM handling and more robust CVE analysis”