DEV Community: Raghu Bharadwaj

Kernel & Embedded News: Android Binder Goes Rust-Only in Linux 7.4

Raghu Bharadwaj — Tue, 22 Sep 2026 05:47:27 +0000

Android's Binder driver is set to lose its C implementation in Linux 7.4, leaving the Rust implementation as the only one — the first time Rust replaces a deployed C driver in the mainline kernel instead of being added beside one. Two large RFCs from Google engineers question old assumptions: io_uring workers that exchange thread identities to avoid worker-thread overhead, and virtual machines that keep executing while the host kernel reboots. Amlogic announced the first Cortex-A320 SoCs for low-power edge AI, and Ubuntu 26.10 completes its move to Rust coreutils.

This edition is about replacement. Two items replace long-lived C code with Rust, one at the kernel level and one in userland; two more propose replacing settled assumptions about what a thread is and what a host reboot means. The fifth brings Armv9 down into a class of silicon that has run Armv8 little cores for a decade.

In this edition

Android Binder drops its C implementation in 7.4. The Rust driver, upstream since 6.18, becomes the only Binder — and Rust becomes a hard build requirement for Android kernels. — planning signal
io_uring may swap thread identities to avoid blocking costs. A 15-patch RFC lets a worker thread take over the submitting thread's identity only when an operation actually blocks. — long-term watch
"Orphaned VMs": guests keep running while the host kernel is offline. A 46-patch RFC extends the Live Update Orchestrator so vCPUs keep executing across a host kexec reboot. — architecture watch
Amlogic announces the first Cortex-A320 SoCs. The A123X and C305X2 pair Arm's smallest Armv9 core with an 8 TOPS Transformer-capable NPU for cameras and battery devices. — hardware watch
Ubuntu 26.10 completes the Rust coreutils transition. cp, mv and rm switch to the Rust implementations, the final three commands to move. — test now

Android Binder drops its C implementation

Carlos Llamas of Google has posted the patch that removes the C implementation of Binder, Android's central inter-process communication driver, from the kernel: 11,470 lines deleted across twenty files. The standard Binder configuration option is rewired to require Rust support, and the module name that vendor build systems reference now points at the Rust driver. Greg Kroah-Hartman has picked the patch up for the char-misc tree, aimed at the 7.4 merge window that opens after 7.3 releases in the second half of October.

The replacement was prepared over several years. The Rust Binder driver began as a demonstration by Wedson Almeida Filho and has since been maintained by Alice Ryhl; it was upstreamed in Linux 6.18, reached full feature parity rather than a convenient subset, and measures equal to or better than the C driver in performance. It has been running on shipping Android hardware for some time. Llamas' stated reason for the removal is that fifteen years of accumulated complexity made the C driver painful to maintain, with new features hard to land without introducing vulnerabilities — a fair description of a driver that is performance-critical, reference-counted, and reachable from untrusted application code.

For the first time, a Rust implementation is replacing a widely deployed C driver in the mainline kernel instead of being added beside one. Every Rust milestone before this was additive: a new driver, an abstraction layer, an optional alternative. Deleting the C path makes Rust a hard build dependency for any kernel that needs Binder — in practice, every Android vendor kernel, and any distribution kernel that supports Android container stacks.

The patch is queued, not merged, and the 7.4 window has not opened; there has been no visible opposition on the list. Binder also had a motivated corporate owner funding its rewrite to parity for years — most subsystems have no equivalent sponsor, so this is a milestone, not yet a pattern.

What it means for Android and embedded teams

Teams building Android on vendor kernels at 6.6 or 6.12 are not affected until their BSP rebases to 7.4 or later, but the direction is now set: a working Rust toolchain in the kernel build becomes as basic as a working C compiler for Android work. Check today whether your kernel CI can build with Rust enabled, and treat the ability to read Rust kernel code as a near-term skill requirement for anyone who debugs IPC on Android systems.

io_uring proposes exchanging thread identities

Jens Axboe, the io_uring maintainer, posted a 15-patch RFC on 11 September with an unusual answer to an old problem. io_uring promises not to block the submitting thread, but several operations — fdatasync, statx, some openat paths — run through kernel code that was never written to be asynchronous. Today, any such operation is handed to a worker thread up front, paying a wakeup and a context switch even when the operation would have completed without blocking at all.

The RFC issues these operations inline instead, and reacts only when blocking actually happens. A new task flag tells the scheduler to notify io_uring when the submitting thread is about to sleep. At that moment an idle worker takes over the submitting thread's identity — thread ID, signal state, credentials, rseq and robust lists, scheduling attributes, register state — and returns to userspace in its place. The original thread, now carrying the worker's identity, sleeps, finishes the operation, and joins the worker pool. The cover letter's benchmarks show why it is tempting: an fsync test on tmpfs improved by roughly 700 percent, because the handoff cost is now paid only when blocking is real.

The risk sits in the identity exchange itself. Nothing else in the kernel may hold a reference to either thread's task structure at the moment of the swap, so the series carries a long list of disqualifying conditions: threads under ptrace, threads using perf events, kernel-tracked futex ownership, realtime scheduling policy, core-scheduling cookies, an in-progress vfork, and more. Peter Zijlstra noted that shadow stacks — enabled on most current x86 deployments — currently disqualify the handoff too, though Axboe believes the shadow stack can move with the identity. Reception on the list is best summarised by Gabriel Krisman Bertazi's verdict: "really cool and seems like very dangerous thing".

How to read this if you build on io_uring

There is nothing to adopt yet; Axboe himself frames the series as a viability question, not a merge candidate. Two details deserve attention from embedded readers. Realtime scheduling excludes the handoff by design, so PREEMPT_RT systems would keep the current worker-thread behaviour and see none of the gains. And the regressions in the RFC's own numbers appear at high queue depths on operations that always block, so the win is workload-specific.

Orphaned VMs: guests that outlive the host kernel

Pasha Tatashin of Google posted a 46-patch RFC on 20 September that pushes the Live Update Orchestrator one step further. LUO, upstream since 6.19 and built on the Kexec Handover infrastructure, preserves selected state across a kexec reboot so a host kernel can be replaced under running workloads; that base is still being completed upstream. The new proposal keeps virtual machines actually executing instructions while the host kernel is down.

The mechanism is called an orphaned VM: guest vCPUs continue on physical CPUs that are shielded from the reboot, while a small privileged interpose layer named the Caretaker traps VM exits and resolves what it can locally — with no host kernel and no VMM present. The series preserves vCPU file-descriptor state across the reboot gap, protects the reserved CPUs from boot-time reset signals, and deals with timekeeping drift, stray interrupts, and guest-to-guest IPI routing during the window. It has been tried on Intel, AMD and Arm server processors; the author calls it early-stage work seeking feedback, ahead of discussion at the Linux Plumbers Conference in Prague next month.

The pattern matters more than the patches. Cloud providers are systematically removing the reboot as a source of downtime, and the building blocks they are upstreaming — Kexec Handover, LUO, now the Caretaker concept — are generic kernel infrastructure, not cloud-only code.

What it means for fleet and hypervisor designs

Industrial and telecom edge systems have the same problem in a smaller form: a gateway running a hypervisor cannot take the guests down every time the host kernel needs a security update. Nothing here is deployable yet, and the vCPU-preservation work targets large servers first. The realistic action is to study LUO and Kexec Handover now — both are documented in the kernel tree — because kexec-based live update is becoming the upstream answer to host maintenance. Product architectures that assume a full-stack reboot for every kernel fix should be re-examined against it.

Amlogic announces the first Cortex-A320 SoCs

Amlogic has announced the A123X and C305X2, the first announced SoCs built on Arm's Cortex-A320 — the smallest Armv9 core, introduced by Arm in February 2025 with SVE2 vector extensions. The A123X carries four A320 cores for industrial machine vision: dashcams, robots, access control, video conferencing. The C305X2 carries two, aimed at battery devices such as solar doorbells and battery IP cameras, with always-on video and pre-roll low-power modes. Both are fabricated on a 6 nm process and pair the CPUs with Amlogic's 8 TOPS ADLA3 NPU, which accelerates Transformer operators in hardware; both also carry an ADLA2 NPU — rated at 4 TOPS on the A123X for CNN workloads, and serving the AI-ISP on the C305X2 — plus a neural audio-event engine and a low-light AI-ISP.

The vendor's headline numbers: 34 percent higher SPECint2006 than the Cortex-A35 this class of chip typically used, and roughly ten times the ML throughput from SVE2. The software story is thin so far — Linux compatibility, reference designs and NN SDKs are promised, with no public datasheets or block diagrams yet. Chips are sampling now, with mass production scheduled for the fourth quarter of 2026. All details are preliminary and come from the vendor's own announcement.

The significance is the class of device. Camera and doorbell SoCs have run Armv8 little cores for a decade; Armv9 in this segment brings SVE2, and with it a vector baseline that inference libraries can target instead of hand-written NEON paths. On-device Transformer support in an 8 TOPS NPU also signals where vendors expect small-model workloads to run.

How to evaluate the first Cortex-A320 parts

Treat these as roadmap information, not design-in candidates, until an SDK and datasheets exist. The questions that decide usability will be familiar: which kernel version the BSP ships, whether the NPU stack is usable outside the vendor's pipeline, and what the upstreaming position is — none of which the announcement answers. Teams selecting camera silicon for 2027 products should add A320-based parts to the comparison table now and press vendors on the software questions early.

Ubuntu 26.10 finishes the move to Rust coreutils

Canonical has completed a transition that began with Ubuntu 25.10: as of the 26.10 development release, cp, mv and rm come from the Rust coreutils project rather than GNU coreutils. Those three commands had stayed on the GNU implementations through 25.10 and 26.04 LTS because of compatibility issues that upstream uutils has since resolved. The 26.10 draft release notes now record the transition as complete, with the beta due this month and the stable release planned for 15 October, targeting Linux 7.3 as its kernel.

Taken with the Binder item, the pattern is clear: in the same month, the reference C implementation of a core Android kernel driver and the last GNU file utilities in a major distribution are both replaced by Rust implementations. Both moves rest on the same argument — memory-safe reimplementations have reached practical parity.

For embedded teams the relevant surface is scripts. Two decades of shell scripts encode GNU-specific behaviour in rarely used options, exact error messages, and edge-case handling.

How to check your images and scripts

If your build or device images derive from Ubuntu, run your provisioning and CI scripts against a 26.10 beta image before the October release reaches your base-image pipeline. Pay attention to scripts that parse cp, mv or rm output or rely on obscure options, and to anything that assumes GNU-specific error text. Debian-based and Yocto-based images are untouched by this change, but the wider ecosystem trend is worth noting in platform decisions.

References

— Raghu Bharadwaj

If you want to go deeper than the news, TECH VEDA runs live, instructor-led training on Linux kernel internals and embedded Linux — see Linux Kernel Infrastructure.

Boot Confirmation: Who Decides an Update Worked?

Raghu Bharadwaj — Sat, 19 Sep 2026 16:37:41 +0000

A successful install is not a successful update. For boot confirmation, use a bootloader boot counter to catch the failures where the system never reaches userspace, and one userspace health check that confirms the slot only after the device has shown it works and can still be updated. Run a hardware watchdog under both, so a hang produces a reset that the counter records. A boot counter alone is enough only when someone can physically reach a failed device.

An update framework reports that the installation succeeded. That means only that the image reached the inactive slot and its checksum matched — nothing about whether the device will boot it, or whether the software works. Boot confirmation answers those two questions: the booted system reports back to the bootloader, which then stops treating the new slot as unproven. The decision is who may make that report, and on what evidence. It goes one level deeper than my post on choosing an A/B update layout, which covered where the slots go.

The context

The SWUpdate documentation defines a successful update as four steps: the update agent runs, the device reboots, the bootloader starts the new software, and that software runs, checks itself, and declares the transaction complete. Three of the four happen after the update agent has exited. Boot confirmation has to catch two classes of failure there, and no single component sees both.

The first class never reaches userspace. A device tree that does not match the board, a panic in early init, an unresolvable root filesystem UUID, a hang while probing a bus. No userspace runs, so none of it can report anything. Only the bootloader can notice, and only if it counts.

The second class boots cleanly and is still a dead product. The system reaches a login prompt, but the radio never associates, a migration fails, or the main service restarts in a loop. The bootloader cannot see this; as RAUC's documentation notes, such problems appear only at runtime, sometimes only after days and many reboots.

The boot confirmation options

Option A — a bootloader boot counter

U-Boot implements this as Boot Count Limit (CONFIG_BOOTCOUNT_LIMIT). After a power-on reset bootcount is initialised to 1, and while upgrade_available is non-zero each reboot increments it by one. When bootcount exceeds bootlimit, U-Boot executes altbootcmd instead of bootcmd. Two details matter on a headless device: if bootlimit is undefined the feature is disabled entirely, and if altbootcmd is undefined U-Boot drops into interactive mode and stays there. Linux must then reset bootcount to 0 to allow further boot cycles.

raghu@techveda.org:~$ fw_printenv bootcount bootlimit upgrade_available
bootcount=1
bootlimit=3
upgrade_available=1
raghu@techveda.org:~$ sudo fw_setenv upgrade_available 0
raghu@techveda.org:~$ sudo fw_setenv bootcount 0

RAUC's U-Boot backend layers its own variables on this, BOOT_ORDER and BOOT_<bootname>_LEFT, driven by a boot script. Barebox instead provides a maintained framework, bootchooser, keeping remaining_attempts and priority per target in an atomic, redundant backend — which is why RAUC's documentation recommends it.

A counter is small, runs before your code, and does not depend on the application. But it counts boots, not correctness: a device that boots with a dead application passes. The state must also be written atomically — on U-Boot, a redundant environment (CONFIG_SYS_REDUNDAND_ENVIRONMENT, spelled that way upstream) outside the bootloader partition — or a power cut mid-write leaves the device unable to decide anything.

Option B — a userspace health check

Here the running system decides. RAUC provides rauc status mark-good and mark-bad, which reach the bootloader through its bootloader interface. The documentation suggests running mark-good from a systemd unit ordered after the services that actually matter, not at the end of boot.

SWUpdate expresses the same idea through a persistent variable, ustate. It is set to 1 (INSTALLED) after an update, meaning the new software is under test; the bootloader initiates a fallback and sets it to 3 (FAILED) if that software is not running; userspace resets it to 0 once confirmed. The documentation is explicit that resetting it is project specific, and can be the last action after the application has checked itself.

This is the only mechanism that can judge whether the product works, and you choose the evidence. But it reports nothing if it never runs, so alone it leaves the first failure class uncovered. Too permissive, it confirms broken builds; too strict, it rolls back a healthy device. The SWUpdate best-practice guide warns of a deeper risk: tying the check to your application makes the application a dependency of updatability.

Option C — both, over a hardware watchdog

A counter only increments if the device reboots, and a system that hangs does not reboot. A hardware watchdog converts a hang into a reset. RAUC states this directly: the system should use a hardware watchdog during boot, and the bootloader should treat watchdog resets as failed boots.

On Linux the watchdog starts when /dev/watchdog is opened, then must be pinged by a write or by WDIOC_KEEPALIVE. If a process closes the device without first writing the magic character V, a Magic Close driver keeps it running; CONFIG_WATCHDOG_NOWAYOUT removes the ability to stop it at all. Under systemd, RuntimeWatchdogSec= programs it and systemd contacts it at least once every half of that interval — but it defaults to 0, meaning off. For coverage before Linux starts, U-Boot has CONFIG_WATCHDOG_AUTOSTART (on by default, except ARCH_SUNXI, ARCH_STM32MP and ARCH_SNAPDRAGON), and barebox uses boot.watchdog_timeout.

The decision

For a connected product you cannot physically reach, use all three layers with different jobs. The watchdog detects that progress stopped and forces a reset. The boot counter detects repeated failed attempts and switches slots. One health check decides the new software genuinely works, and confirms.

Three rules make that practical. Define the health check as the smallest set of conditions meaning the device performs its function and can be updated again, including the update agent's reachability. Keep the confirmation path independent of the application. And set bootlimit to at least 3, so one transient failure does not cause a rollback.

The boot counter alone is the right choice in two situations. If a technician can reach and reflash a failed device, a dead application and a dead boot are the same service call. And if the application team cannot commit to a stable health signal, a check whose meaning changes every release produces rollbacks nobody can explain.

A userspace check alone is the right choice when the vendor boot chain is locked and you cannot add counting logic. Put the fallback decision in an initramfs or an early service that runs before the application.

Consequences

The health check becomes release-critical code. It ships inside the image it validates, so version it with that image, and test the rollback path each release with a bundle known to fail.

You acquire a timing budget. The watchdog timeout must exceed the worst-case boot, including a filesystem check and any first-boot migration; otherwise a slow but healthy boot is indistinguishable from a broken one. U-Boot's CONFIG_WATCHDOG_TIMEOUT_MSECS defaults to 60000 with per-architecture overrides — measure it on your hardware.

Rollback is not free at the data layer either. Returning to older software leaves newer data on the writable partition, so a schema written by the new version must still load on the old one — a constraint belonging to the application, not the update framework. You also need to explain a rollback afterwards, so record the watchdog boot status (WDIOC_GETBOOTSTATUS, WDIOF_CARDRESET) and ustate or BOOT_<bootname>_LEFT.

Finally, one boot confirmation failure mode is easy to miss. If no device in your fleet has ever rolled back, the likely explanation is not that every release was perfect; it is that the health check tests nothing. Keep a rescue system regardless, because a double-copy setup still has failure modes affecting both copies.

Key takeaways

A successful installation is not a successful update; boot confirmation decides whether the new slot is kept.
A boot counter catches failures that never reach userspace; a health check catches a device that boots but does not work. Neither covers the other.
A hardware watchdog turns a hang into a reset the counter can observe; under systemd it is off by default. Keep the health check small, and always include the ability to receive another update.

Frequently asked questions

What is boot confirmation?
It is the step where a newly booted system reports back to the bootloader that it is working, so the bootloader stops treating the new slot as unproven. Until then, returning to the previous slot stays possible.

Is a bootloader boot counter enough on its own?
Only when someone can physically reach a failed device, or when the application cannot provide a stable health signal. A counter measures boots, not correctness, so a device that boots with a dead application passes it.

What should the userspace health check actually test?
The smallest set of conditions meaning the device performs its function and can still receive another update. Include the update agent's reachability, so a bad release stays replaceable.

Why is a hardware watchdog needed if the bootloader already counts boots?
A counter only increments when the device reboots. A system that hangs does not reboot, so the failure is never counted. The watchdog forces the reset that makes it visible.

Containers vs Packages: Delivering Apps on an Embedded Device

Raghu Bharadwaj — Wed, 16 Sep 2026 04:54:22 +0000

Keep the application inside the base image until the platform team and the application team release on different schedules. At that point deliver it as a separate signed artifact, replaced as a whole, not as packages installed on the running device. In the containers vs packages comparison, containers suit several independently released applications; a runtime package manager is the option to avoid in production, because it lets every unit in the field reach a different state.

Assume the platform decision is settled: the device boots from an A/B root filesystem built by Yocto or Buildroot, and the update client installs a signed bundle and rolls back after a failed boot. One question is usually still open, and is decided by default rather than by design: where does the application live, and how does a new version reach it? The containers vs packages framing covers the two answers teams argue about most, but four are worth weighing.

The context

The decision arises the first time two groups ship on different calendars. The platform group updates the kernel, the BSP and the base userspace every few months; the application group wants to ship a fix on a Thursday. With only a full base image to carry it, that fix needs a full platform release.

Release cadence. One image means one cadence for everything inside it.
Flash budget. In a symmetric A/B layout the root filesystem is stored twice: a 400 MB model file costs 800 MB.
Integrity. A read-only root verified with dm-verity cannot be written to after the build.
Rollback. A base rollback restores the base, not an application from another channel.
Test surface. Every independent channel multiplies the version combinations in the field.

If the A/B layout is not settled, decide that first; we covered it in Choosing an A/B Update Layout for Your Product.

Containers vs packages: the four options

Option 1: the application lives in the base image

The application is a recipe in your build system, lands in the root filesystem, and is updated by shipping a new base image. One artifact, one version number, one test matrix. Buildroot's manual states the position directly: binary packages allow partial upgrades, creating a large number of version combinations that would have to be tested, whereas replacing the whole image guarantees the system in the field is the one that was tested.

For: simplest integrity story, works with a read-only verified root, one version to support.
Against: one cadence for all software, a full download for a one-line fix, a reboot for every application change, duplicated flash.

Option 2: a runtime package manager on the target

Yocto can produce this. Adding package-management to IMAGE_FEATURES ships the package databases and the target-side package tools in the image, so the device can install and upgrade from a feed at runtime. PACKAGE_CLASSES selects the backend: package_rpm, package_deb or package_ipk. Buildroot does not offer this at all, because it does not track which package installed which file.

For: small incremental updates, and useful on development images where you want strace or gdb without a rebuild.
Against: incompatible with a read-only or dm-verity-protected root; dependency resolution runs on the device, so units drift apart; a compromised feed or signing key lets the device install arbitrary software.

Option 3: OCI containers

The application ships as a container image and a runtime such as Podman or Docker starts it. On Yocto this comes from the meta-virtualization layer, which carries the runtime recipes and expects virtualization in DISTRO_FEATURES. The base image stays read-only; the container store lives on the writable data partition.

For: the application and its dependencies travel together, so it does not depend on the libraries the base image carries; applications from different teams are versioned separately; namespaces and resource limits give isolation.
Against: the runtime, its storage layers and its network configuration are more software to harden and track for CVEs; the image store needs a writable filesystem; and the container layer gives no rollback of the base.

Option 4: a separate artifact, without a container runtime

Independent versioning does not require containers. Three mechanisms are worth knowing.

RAUC artifact repositories. RAUC installs artifacts into named repositories rather than into slots; these were added in RAUC 1.13. The cases its manual lists are container and VM images, large data files such as maps or machine learning models, firmware for other microcontrollers, and optional add-on services. An artifact is replaced under the same name, independently of the base and usually without a reboot.
systemd system extension images (sysext). A read-only image that extends /usr/ and /opt/ at runtime by overmounting them with an overlayfs. Images go in /var/lib/extensions/, and each carries an extension-release file whose ID= and SYSEXT_LEVEL= or VERSION_ID= must match the host, so compatibility is checked at merge time, before basic.target. In systemd since version 248, with no dependency resolution.
OSTree. A content-addressed store of complete filesystem trees. Deployments are hardlinks into /ostree/repo, so an upgrade costs space proportional to the new files plus a constant overhead.

Across all three:

For: independent versioning, single storage rather than one copy per slot, no container runtime.
Against: less common in most teams; no isolation; sysext binaries link against host libraries unless statically linked.

The decision

For the common case — one application, one team owning it, the same cadence as the platform — keep the application in the base image. A second delivery channel that nobody needs is cost without benefit, and it weakens the guarantee that the software in the field is the software you tested.

Once cadences separate, deliver the application as a separate signed artifact. Which mechanism depends on your needs.

Choose containers when you have more than one independently released application, when they come from different teams, or when you need isolation between them.
Choose a RAUC artifact repository or a sysext image when you have one or two applications, no isolation requirement, a tight flash budget, and a team that maintains the build.
Choose a runtime package manager only on development and bench images, or on an edge server whose operations team accepts fleet divergence.

Whichever you choose, write the compatibility contract down before the first field release: which application versions run on which platform versions, and what the device does outside that range. A sysext image enforces this through the extension-release match; otherwise you enforce it. Installing a system extension is:

raghu@techveda.org:~$ sudo cp app-2.4.raw /var/lib/extensions/
raghu@techveda.org:~$ sudo systemd-sysext refresh
raghu@techveda.org:~$ systemd-sysext list

We cover these decisions on real hardware in our Embedded Linux and Yocto training.

Consequences

You are testing a matrix, not a build. With two channels, the platform-and-application combinations grow with every release on either side. Decide which combinations you support and test those.

Rollback stops being one operation. The A/B mechanism rolls the base back after a failed boot, but not an application from another channel, because it is not in the slot being switched. A bad application version needs its own recovery path.

Storage moves rather than disappears. Taking a large payload out of the A/B root filesystem removes the duplicate copy, which is the reason RAUC gives for artifact repositories. But the store needs a writable partition, formatted for your flash.

Attack surface follows the choice. A container runtime is a large body of code you now track and patch. A package manager is smaller, but has a larger consequence if its key or feed is compromised. Baking the application in adds neither.

Read-only roots and package managers do not combine. If you have committed to dm-verity, option 2 is closed. Decide delivery together with the integrity design.

Key takeaways

Application delivery is driven by release cadence, not technology preference.
In the containers vs packages comparison, containers give independent versioning and isolation at the cost of a runtime you maintain; a package manager gives small updates at the cost of fleet divergence.
RAUC artifact repositories, systemd-sysext and OSTree give independent versioning without a container runtime.
Any separate channel needs an explicit compatibility contract and its own rollback path.
dm-verity and an on-device package manager cannot coexist, so decide delivery and integrity together.

Frequently asked questions

Can I put a package manager on a read-only root filesystem?
No. A package manager writes into the root filesystem, and a read-only root has no writable location for it. If that root is protected with dm-verity, any modification breaks hash verification. Use a container image, a RAUC artifact or a sysext image instead.

Does a container update replace the need for A/B base updates?
No. A container image update changes the application only. The kernel, bootloader, drivers and base userspace are still delivered by the base image mechanism, which is the only thing that can roll them back after a failed boot.

How does a separate artifact save flash compared with baking it in?
In a symmetric A/B layout the root filesystem exists in both slots, so a large payload is stored twice. RAUC gives this as the reason for artifact repositories: container images, map files and machine learning models go into a repository rather than a slot, so they are stored once, on a writable partition you then manage.

When does a sysext image fit better than a container?
When you have one or two applications, a read-only base image and no isolation requirement, a system extension gives independent versioning without a container runtime. It fits poorly when you need several mutually isolated applications, because system extensions have no dependency mechanism.

Kernel & Embedded News: Silent Data-Loss Bug Fixed; CRA Reporting Live

Raghu Bharadwaj — Tue, 15 Sep 2026 11:07:16 +0000

A one-line kernel fix has closed a silent data-loss bug present on x86 since Linux 6.6, triggered when transparent hugepages, MADV_FREE and memory pressure combine. The EU Cyber Resilience Act's vulnerability-reporting obligations became mandatory on 11 September 2026, with a 24-hour first-report deadline for actively exploited vulnerabilities. This edition also covers a record wave of more than 9,000 stable-kernel patches in a single day, Yocto 6.1 reaching feature freeze with OpenSSL 4 and the 7.2 kernel, U-Boot's move to new project infrastructure ahead of its 5 October release, and a patch series that makes full kernel builds roughly a third faster.

Two items this week call for direct attention: a data-corruption fix that affects every x86 kernel since 6.6, and a European reporting obligation that is now in force. The other four are planning signals — stable-kernel patch volume has reached a record, Yocto has frozen the feature list for its next release, U-Boot has moved to new project infrastructure, and kernel build times are set to drop.

In this edition

Silent data loss fixed after three years — on x86, writes made after an MADV_FREE call to huge pages could vanish under memory pressure; the one-line fix is headed to every stable series. — patch when your branch picks it up
CRA vulnerability reporting is now mandatory — since 11 September, manufacturers selling into the EU must report actively exploited vulnerabilities within 24 hours. — act now
A record stable wave: more than 9,000 patches in one day — seven point releases at once, with maintainers describing heavy AI-generated patch volume. — process signal for LTS consumers
Yocto 6.1 reaches feature freeze — the release building now carries OpenSSL 4, rpm 6, clang 23.1.0 and the 7.2 kernel. — planning signal
U-Boot moves its infrastructure ahead of v2026.10 — rc4 is out, the old lists server is shut down and source.denx.de redirects to git.u-boot-project.org; the final release is due on 5 October. — check your pinned URLs
Kernel builds set to get a third faster — a 23-patch series removes single-threaded bottlenecks in the build process, aimed at Linux 7.4. — worth testing

A silent data-loss bug, present since Linux 6.6, is fixed with one line

On 2 September, Orson Peters, a developer of the Polars data-analytics library, posted a short C reproducer to the kernel's memory-management list: fill a buffer, call madvise(MADV_FREE), write the buffer again, and under cgroup memory pressure the second write can disappear. Later reads return zero-filled pages, with no error reported anywhere. Polars users had already lost production data this way.

Vernon Yang identified the cause within a day. Since the x86 shadow-stack preparation work that shipped in Linux 6.6, pmd_modify() has stripped the hardware dirty bit from PMD-mapped transparent hugepages. Memory reclaim then finds a lazy-freed folio with no dirty bit set anywhere and discards it, even though the application rewrote the data after the MADV_FREE call. NUMA balancing can trigger the same loss on its own, and PMD-mapped file THPs can silently miss writeback.

The fix restores _PAGE_DIRTY to the preserved mask — one changed line in arch/x86/include/asm/pgtable.h. Rick Edgecombe, author of the original shadow-stack series, reviewed it and confirmed the stripping was an unintended leftover, and a SUSE engineer reported an independent customer case that the patch resolved. It was merged into mainline after 7.3-rc3 and is tagged for the stable trees. Every x86 kernel from 6.6 to the current 7.3 release candidates carries this bug; arm64 devices are not affected.

The trigger conditions read narrow — huge pages, MADV_FREE, reclaim pressure — but they describe ordinary modern deployments. Memory allocators issue MADV_FREE on their own, and cgroup memory limits are standard under systemd and in containers. x86 industrial PCs, edge gateways and build servers are all in scope.

How to check your device

You are exposed if the machine is x86, runs kernel 6.6 or newer, has transparent hugepages enabled, and runs any software that calls MADV_FREE — memory allocators are the usual source. Two commands answer the first three questions:

raghu@techveda.org:~$ uname -rm
6.12.110 x86_64
raghu@techveda.org:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

If the bracket sits on always or madvise, plan the update. The fix is tagged for stable, so expect it in the next rounds of 6.6.y, 6.12.y, 6.18.y and 7.x.y point releases — take the whole point release rather than the single patch. Until it lands, booting with transparent_hugepage=never removes the trigger, at a measurable performance cost. arm64 fleets need no action on this one.

CRA reporting is no longer a future obligation

Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, began to apply on 11 September 2026. From that date, a manufacturer of a product with digital elements sold in the EU must report an actively exploited vulnerability in the product, or a severe incident affecting the product's security, through ENISA's Single Reporting Platform — which went live the same day. One submission reaches both the coordinating national CSIRT and ENISA.

The deadlines are short. An early warning is due within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days for an actively exploited vulnerability once a corrective measure is available, or within one month for a severe incident. The bulk of the CRA — the essential cybersecurity requirements and CE marking — applies from December 2027, but the reporting duty is in force now, with penalties of up to €15 million or 2.5% of global turnover.

A legal deadline presupposes detection. A team cannot file an early warning within 24 hours for a vulnerability it learns about weeks late, so monitoring the kernel CVE feed for the exact version a product ships, tracking vendor BSP advisories, and keeping an accurate SBOM stop being internal good practice and become inputs to a statutory deadline. Our weekly kernel CVE roundups and the support-clock analysis describe the monitoring side of exactly this problem.

What it means for manufacturers

Confirm scope first: the obligation attaches to the manufacturer of a product with digital elements placed on the EU market, wherever the manufacturer is based. An India-based device maker exporting to the EU is covered.
Route vulnerability intelligence — the kernel CVE feed filtered to your shipped versions, plus vendor advisories — into a channel someone is responsible for watching, not into an individual inbox.
Assign the 24-hour reporting duty to a role with backup coverage, and register on the Single Reporting Platform before the first incident, not during it.
Run one internal dry run of a report so the first real submission is not a first attempt.

Seven stable kernels, more than 9,000 patches, one Monday

On 14 September Greg Kroah-Hartman released seven stable kernels at once — 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221 and 5.10.270 — carrying more than 9,000 patches between them. He noted the batch may set a record for patch count; 7.2.6 alone contains more than 1,800 patches.

The volume has a context. In the 7.3 networking pull, Jakub Kicinski, who maintains the networking trees with Paolo Abeni, counted 632 net and 648 net-next patches for the cycle and estimated that a third to half of the net-next patches appeared to be AI-driven low-priority fixes, clean-ups and clarifications. He described the maintainers as "completely overwhelmed", noted that Meta funded enough LLM access to run each incoming patch past several frontier models as a review aid, and said the next step is pointing the tools at process work — managing patchwork, editing commit messages, applying patches already reviewed by trusted people.

Machine-assisted bug finding is filling the stable queues faster than human review capacity grows. Patch count is not risk count — most of these changes are small, machine-found and low severity — but the practical consequence for anyone consuming LTS kernels is that point releases are getting larger while the weekly cadence stays the same. Skipping releases now builds a bigger, riskier delta than it did a year ago, and vendor kernels that cherry-pick individual fixes fall behind the stable tip faster.

What it means for teams consuming LTS kernels

Take whole point releases on a fixed schedule instead of accumulating a backlog; the cost of catching up is growing quarter by quarter.
Put the effort into automated boot and workload regression tests. Reading 1,800 patches per release is not a realistic review strategy for a product team.
When evaluating a vendor BSP, ask how it consumes stable updates — full point releases or selected backports — and how far behind the stable tip it currently is.

Yocto 6.1 freezes: OpenSSL 4, rpm 6, kernel 7.2

The Yocto Project's weekly status reports place YP 6.1 at Milestone 3 feature freeze, with the M3 build due for release in the week of 14 September and the 6.1.0 release scheduled for the week of 2 November. The stated merge intent for M3 is rpm 6, OpenSSL 4, clang 23.1.0 and the 7.2 Linux kernel. On the stable side, 6.0.3 for the Wrynose LTS has been released, 5.0.20 is in QA, and 6.0.4 is planned for mid-October.

The OpenSSL jump is the item to plan around. OpenSSL 4.0, released on 14 April 2026, removes ENGINE support along with other legacy interfaces. Anything in a layer stack that still loads an OpenSSL engine — afalg or devcrypto for kernel crypto offload, a vendor's hardware crypto engine, an older PKCS#11 engine build — stops working; the provider API is the replacement. Yocto 6.1 is where much of the embedded ecosystem meets that removal for the first time.

The status reports also record that changes to GitHub's bot and AI protection disrupted the project's CI, and that AI scrapers continue to consume significant sysadmin time and money — the same pressure the kernel's own infrastructure reported two weeks ago. Defending infrastructure from automated crawlers is now permanent work for community build systems.

What it means for Yocto-based products

Most product teams will stay on 6.0 Wrynose LTS, and what that LTS does and does not maintain still applies — but 6.1's package set is the version baseline the ecosystem targets next. Treat it as the preview of your next migration.
Search your layers now for OpenSSL engine usage: ENGINE_ API calls, openssl engine invocations, and afalg/devcrypto/pkcs11 engine configuration. Every hit is migration work toward providers.
If you consume package feeds, note the rpm 6 move; if you track linux-yocto, the 6.1 baseline is kernel 7.2.

U-Boot: one release candidate left, and new project infrastructure

Tom Rini released U-Boot v2026.10-rc4 on 7 September, carrying platform updates for Marvell, NXP Layerscape/QorIQ, i.MX, AMD/Xilinx, Renesas R-Car, Rockchip and STM32, plus fixes in the EFI loader, FPGA, DFU and networking code. One more release candidate is expected in two weeks, and the final v2026.10 release is scheduled for 5 October.

The announcement also records the next stage of the project's infrastructure migration. The old lists.denx.de server has been shut down, and source.denx.de/u-boot now redirects to git.u-boot-project.org/u-boot, where the git tags and release archives are published. Account registration on the new server will move from open to closed, and the project states it is not planning a web pull-request model — patches stay on the mailing list.

The redirect keeps existing fetches working today, but the project has not said how long it will remain in place. U-Boot is pinned by URL in a large number of places that outlive any one server: Yocto SRC_URI entries, Buildroot custom-repository settings, repo manifests, and CI mirror configurations.

How to check your build

Search your layers, manifests and CI configuration for the old hostnames and update the pins to git.u-boot-project.org at the next planned change:

raghu@techveda.org:~$ grep -rn "denx.de" layers/ manifests/ .gitlab-ci.yml

If a rebase to v2026.10 is on your roadmap, begin board testing on rc4 now — only one release candidate remains before the 5 October release.
Bookmark the release archive location under git.u-boot-project.org; scripts that scrape the old paths will eventually stop working.

Kernel builds are set to get a third faster

Lorenzo Stoakes of Arm posted a 23-patch series on 8 September that removes single-threaded bottlenecks across the kernel's build plumbing — kallsyms, modpost, objtool, mksysmap and the Rust build — followed by a second revision on 14 September. The measured results: full allmodconfig builds around 36% faster, incremental builds up to 70% faster, and no-op rebuilds around 90% faster. Two of the patches are already merged, and the rest are aimed at Linux 7.4.

The method deserves attention alongside the numbers. An LLM was used to locate the bottlenecks and generate first-draft code — Stoakes wrote that it produced "a lot of code, much of it hideous" — after which he audited and rewrote it, verified correctness and performance manually, and marked every commit with an Assisted-by tag. In the same week that networking maintainers described being overloaded by machine-generated submissions, this series shows the same tools producing reviewable, wanted work. The difference is the position of the human: an expert applied the tool to a problem he owns and audited every line, instead of passing unreviewed output to someone else.

How to use it

Product kernels need no action; if review holds, the improvement arrives with the 7.4 build system, and faster CI follows from upgrading.
Developers doing iterative kernel work can apply the v2 series to a test tree today and measure their own incremental build times — that is the case the 70% figure describes.
The tagging convention is worth copying: an explicit Assisted-by record on machine-assisted commits keeps the review honest and the history auditable.

References

TECH VEDA runs live, instructor-led training on the Linux kernel, device drivers and embedded Linux — programs and schedules at techveda.live.

— Raghu Bharadwaj

A Certified Hypervisor Does Not Cover the Linux Guest

Raghu Bharadwaj — Sat, 12 Sep 2026 07:50:09 +0000

TÜV Rheinland's public certificate register lists QNX Hypervisor for Safety under number 968/FSP 1976.08/26, assessed against ISO 26262-2:2018, ISO 26262-6:2018 and ISO 26262-8:2018 and usable as a Safety Element out of Context to realise safety goals up to ASIL D. The type designation on that entry is the hypervisor. It is not the guests the hypervisor hosts, and the standards list does not include ISO 26262-9:2018, which is the part covering criteria for coexistence of elements and analysis of dependent failures. A Linux guest placed beside a certified hypervisor inherits a partitioning mechanism, not a safety argument.

Engineers consolidating an instrument cluster, an infotainment surface and a body-control function onto one system-on-chip are usually told the same thing by the platform team: the hypervisor is certified, so the Linux side is isolated and stays outside the safety argument. The first half of that sentence can be checked in a public register in about two minutes. The second half is not written anywhere in the certificate. This post reads the actual register entry for a certified hypervisor, states what its scope covers, and works through what a Linux guest sitting next to it still owes the person who has to build the item.

What the public register actually records

TÜV Rheinland publishes its functional-safety product certificates in a searchable database at fs-products.tuvasi.com. Read on 12 September 2026, that database showed 7,042 records with a dateline of 09-2026. Two entries in it matter to anyone relying on a certified hypervisor, and QNX links to both from its own certifications page.

The first is certificate 968/FSP 1976.08/26. The certificate holder and manufacturer is BlackBerry Limited. The product category is Software with the sub-category Others, the subject is recorded as "Hypervisor", and the type designation is "QNX Hypervisor for Safety (QHS)", with released and approved versions deferred to a separate revision list. The codes and standards are given as six documents: IEC 61508-1:2010, IEC 61508-3:2010, ISO 26262-2:2018, ISO 26262-6:2018, ISO 26262-8:2018, and IEC 62304:2006 with Amendment 1:2015, the last one explicitly excluding clauses 4.2 and 4.4. The scope states that the product complies with the requirements of those standards at ASIL D according to ISO 26262, SC 3 according to IEC 61508 and Class C according to IEC 62304, and that it can be used as a Safety Element out of Context in items in order to realise safety goals up to ASIL D.

The second is certificate 968/FSP 2999.02/26, for QNX OS for Safety, categorised as Software and subject "Real Time Operating System (RTOS)". It names the same six standards and reaches the same integrity levels. It also does something more interesting, which is to scope the product internally. The register entry states that the provided tool chain, classified as TCL3 and T3, complies with the applicable requirements for supporting tools according to ISO 26262-8 and off-line support tools according to IEC 61508-3. It then splits the C++ library in two: the runtime components can be used to realise safety goals up to ASIL D, while the C++ library headers and templates can be used only up to ASIL B according to ISO 26262 and SIL 1 according to IEC 61508.

That split deserves attention, because it is the clearest available demonstration that a certificate is a statement about parts of a product rather than about a product. Two pieces of the same shipped library, from the same vendor, under one certificate number, carry different integrity ceilings. An application that instantiates a template from that library inside an ASIL D function cannot lean on the certificate for that instantiation. The register does not record the assessor's reasoning, so this post does not offer one. What it does record is the boundary, and with a certified hypervisor as with a certified library, the boundary is the thing an integrator has to design around.

Both entries carry the same two administrative facts. Under "Valid Until" each says "no expiry date". Under "Specific Provisions" each says that the operating conditions and functional characteristics specified in the Safety Manual and accompanying documents must be observed, and that the current versions of software are specified in the currently valid revision list, released by the manufacturer in cooperation with the certification body. The hypervisor entry's revision list is dated 12 March 2026; the OS entry's is dated 13 March 2026.

The strongest case for putting the critical function on the microkernel

Before any Linux-side response, it is worth stating plainly why a functional-safety engineer picks a certified microkernel, and a certified hypervisor above it, for the domain whose failure can injure a person, because the reasons are good ones and they are not commercial.

The first is that the evidence already exists and has a reference number. An integrator can put "968/FSP 1976.08/26" into a safety plan and an assessor can look it up. That is a different situation from having to construct a qualification argument for a component from scratch, and the difference shows up in schedule and in cost.

The second is that Safety Element out of Context is a real division of labour, not a label. The supplier has performed development activities against ISO 26262-2:2018 and ISO 26262-6:2018 and hands over a Safety Manual containing the assumptions it made about the context it would be used in. The integrator's remaining job is to check those assumptions hold in the actual item and to document where they do not. That is bounded work that can be planned and staffed. Building the equivalent evidence for an uncertified component is not bounded in the same way.

The third is the tool chain. ISO 26262-8:2018 lists confidence in the use of software tools among its subjects, and qualifying a compiler is a substantial exercise on its own. The QNX OS for Safety register entry places the supplied tool chain inside the assessed scope at TCL3 and T3. Anyone who has priced a compiler qualification separately will understand what that is worth.

The fourth is architectural. A microkernel moves device drivers, file systems and protocol stacks out of the privileged kernel and runs them as ordinary user-space processes. The code executing at the highest privilege level is therefore much smaller than in a monolithic kernel, and a fault in a driver is a fault in a restartable process rather than a fault inside the trusted computing base. The QNX Hypervisor for Safety 8.0 solution brief describes exactly this arrangement, with the QNX scheduler managing guest execution and separate process and memory managers enforcing isolation and controlled shared memory.

The fifth is timing. The same brief states that the hypervisor supports Virtualization Host Extensions on ARMv8 AArch64 processors, which lets it run at Exception Level 2, the privilege level the hardware provides for virtualisation, and that this reduces the cost of switching between guests and the hypervisor. It also states that both Symmetrical Multiprocessing and Bound Multiprocessing are supported, so virtual CPUs can be pinned to specific physical cores. Pinning is not a performance optimisation in this context; it is how an integrator removes a scheduling variable from the timing argument.

The sixth is accountability. One company's name sits on the certified hypervisor's register entry, and the revision list is released by that company in cooperation with the certification body. When a defect is found there is one party responsible for the corrective action and one register entry that gains a new revision. An OEM's supplier-quality process is built around exactly that shape.

An engineer who chooses this arrangement for a function with a high integrity target is not dressing up a commercial preference as an engineering one. In choosing a certified hypervisor they are choosing the option where the evidence already exists, where the residual work is bounded, and where somebody else is contractually answerable for the part they did not write.

Where a certified hypervisor stops

The register entry is precise about its subject, and reading it closely tells you where the certified hypervisor's scope ends.

The type designation is "QNX Hypervisor for Safety (QHS)". A guest operating system is not part of that designation. The product's own solution brief states that it enables multiple guest operating systems including Android, Linux and QNX to run on a single system-on-chip. Running a guest is what a certified hypervisor does; certifying that guest is not.

The Specific Provisions field makes the Safety Manual binding. Any claim an integrator makes on the strength of a certified hypervisor is conditional on the operating conditions and functional characteristics that manual states. If the manual assumes a particular configuration and the item ships a different one, the certificate has not been invalidated so much as never applied.

The absence of an expiry date is easy to misread. It does not mean the certificate covers whatever version is current. It means the version coverage lives in the revision list instead, and that list carries a date — 12 March 2026 for the hypervisor entry when this post was written. Moving to a hypervisor build that is not on the current list is a change-impact question, not a free upgrade.

The most consequential omission is in the codes and standards list, and it is an omission by structure rather than by oversight. The list names parts 2, 6 and 8 of ISO 26262:2018. It does not name part 9. ISO 26262-9:2018, "Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses", is Edition 2, published on 17 December 2018, 29 pages, and its ISO catalogue abstract lists its subject matter as requirements decomposition with respect to ASIL tailoring, criteria for coexistence of elements, analysis of dependent failures, and safety analyses. Those are the analyses that decide whether elements of different integrity levels may sit together and whether a single cause can take out more than one of them. They are performed on the item. A product certificate for a hypervisor cannot contain them, because the elements that have to coexist are not known until an integrator picks them. The coexistence question is therefore not answered by buying a certified hypervisor; it is opened by it.

One further scope limit is recorded by the vendor rather than the assessor. The QNX Hypervisor for Safety 8.0 solution brief carries a certification-scope table which marks ISO/SAE 21434, the road-vehicle cybersecurity engineering standard, as complete for QNX OS for Safety and "In Progress" for QNX Hypervisor for Safety. Functional safety and cybersecurity are separate assessments with separate scopes, and a product can hold one without the other.

Three ways a device reaches a guest, and what each costs the argument

The partitioning a certified hypervisor performs becomes concrete at the device boundary. The QNX Hypervisor for Safety 8.0 solution brief states that each virtual machine is configured like a physical board, with memory and devices explicitly assigned to either the guest or the hypervisor, and that a device can be configured in one of three ways.

Configuration	What it means	What it costs the interference argument
Emulated	The hypervisor fully emulates the device, so the guest needs no driver change.	Every device access traps into the host, which costs throughput and adds latency. The emulation code itself sits inside the host's scope and has to be treated accordingly.
Para-virtualised, VirtIO compliant	The guest runs a virtual driver that talks to the host through a standardised interface.	Far fewer traps, and the guest driver is portable because VirtIO is standardised and already in the Linux kernel. The cost is a shared-memory channel between domains, which is a coupling path the analysis has to account for.
Physical pass-through	The guest accesses the physical device directly, at native performance.	The device becomes a bus master under the guest's control. Stage-2 address translation constrains what the guest's CPUs can reach; it does not constrain what a device they program can reach.

That last row is where most of the real engineering sits, and it is the reason the solution brief singles out one component by name. QNX Hypervisor for Safety includes an SMMU manager service, smmuman, which works with the hardware System Memory Management Units to confine Direct Memory Access devices so that DMA-initiated transfers cannot reach memory beyond approved regions. Without a correctly configured SMMU behind a passed-through device, a buggy or compromised Linux guest can program that device to write anywhere in physical memory, including into the safety domain, and no amount of CPU-side partitioning will stop it. The SMMU configuration is therefore not a performance detail. It is load-bearing in the freedom-from-interference argument, and it is configuration the integrator sets and must verify rather than something a certified hypervisor supplies ready-made.

Interference the partition does not remove

Address-space isolation answers one question: which memory can this software name. It does not answer the other one: which resources do these domains share whether they name them or not. On a consolidated system-on-chip, the shared resources are substantial and they all sit below the certified hypervisor.

Both domains draw from the same memory controllers. A Linux guest running a display compositor, a camera pipeline or a container build can lengthen the safety domain's memory access times through queueing at the controller without ever issuing an address the partition would refuse. The same applies to the last-level cache, where pressure from one domain changes the execution-time distribution of the other, and to the on-chip interconnect, where arbitration is shared. Thermal behaviour couples them too: sustained load in one domain raises die temperature and can trigger frequency reduction that both domains experience. Where a GPU or a video engine is shared between a cluster surface and an infotainment surface, the coupling is direct.

Two consequences follow for anyone building the timing evidence. The first is that latency measurements taken with the Linux guest idle are not evidence about the shipped system; the measurement has to be made with the guest under its worst realistic load, and that load has to be described in the evidence. The second is that these coupling paths are properties of the silicon and the workload rather than of the hypervisor, which is precisely why the analysis of dependent failures named in the ISO 26262-9:2018 abstract is item-level work that no supplier can have done in advance.

None of this is a criticism of the QNX product. It applies identically when both domains run QNX. A certified hypervisor decides what software is permitted to name; the silicon decides what the domains physically share. Those are different problems and only the first one has a certificate.

What changed between December 2019 and March 2026

On 9 December 2019, BlackBerry announced that QNX Hypervisor 2.0 for Safety had been recognised as ISO 26262 ASIL D compliant by TÜV Rheinland, describing it as the world's first ASIL D safety-certified commercial hypervisor. The announcement named two standards: ISO 26262 at ASIL D and IEC 61508 at SIL 3. Thomas Steffens of TÜV Rheinland Industrie Service GmbH was quoted in it.

The register entry that exists today is a considerably more detailed object. Certificate 968/FSP 1976.08/26 carries a revision index of .08 and a 2026 registration year. It names six standard documents with their edition years rather than two standard families. It states which IEC 62304 clauses are outside the assessed scope, and separately excludes from the certification the risk-management process that IEC 62304 requires. It attaches a dated revision list for covered software versions. And the product it describes is QNX Hypervisor for Safety 8.0, built on QNX OS for Safety and on QNX Software Development Platform 8.0, according to the product page published on 10 March 2026.

The useful reading of that change is not that the product got better, which the register does not say. It is that a certificate is a maintained object rather than an award. The revision index advances, the covered-version list is reissued with a new date, and exclusions are stated explicitly. An integrator citing a certified hypervisor on the strength of the 2019 headline would be carrying a claim that is now seven years old, would have no idea which software versions are actually covered, and would miss the excluded clauses entirely. The lesson is not specific to this vendor. Before relying on any certified hypervisor, read the register entry rather than the announcement.

What the Linux guest is actually for

The honest answer for the domain with the highest integrity target is that Linux is not the right tool for it today, and the register is the reason. There is no equivalent entry for a Linux kernel at ASIL D. The assessed Linux platform that does exist sits two integrity levels lower: Red Hat announced on 20 May 2025 that Red Hat In-Vehicle Operating System had achieved functional safety certification as a Safety Element out of Context against ISO 26262 Edition 2, 2018, at Level ASIL-B, with exida as the assessor, and stated that customers receive a Safety Guidance document including Assumptions of Use. That is the same shape of deliverable as the QNX Safety Manual, at a different level, from a different assessor. If you want the detail of what a Linux certificate does and does not bound, we covered that separately in what a Linux safety certification actually covers.

What the Linux guest is for is the part of the vehicle that changes. Graphics and display stacks, connectivity, media, camera and sensor pipelines through V4L2, container runtimes, the application layer and the update path. The reason to put that next to a safety domain on one chip is not that it has become safe. It is that the bill of materials no longer supports a separate electronic control unit for it, and that the two halves have incompatible release rhythms. The infotainment surface wants a new build every few weeks. The certified domain wants to move as rarely as possible, because every move reopens a change-impact question against a dated revision list.

That lifecycle separation is the actual commercial driver behind consolidation, and it is what a partition with a documented interference argument buys. It is not isolation for its own sake. What a certified hypervisor is bought for is the ability to ship the fast-moving half without reassessing the slow-moving one.

The open-source side of the industry is converging on the same shape independently. Automotive Grade Linux announced its SoDeV reference platform on 5 December 2025, combining the AGL Unified Code Base with Linux containers, the Unified HMI framework contributed by Panasonic Automotive Systems, VirtIO, the Xen type 1 hypervisor, the Yocto Project and the Zephyr RTOS, with AGL stating that it is collaborating with the ELISA Project to support future ASIL functional-safety applications within SoDeV. The initiative is led by Panasonic Automotive Systems, Honda and the AGL SDV Expert Group, with contributions from Toyota, Mazda, AISIN and Renesas, and availability was planned for early 2026. General-purpose Linux beside a small RTOS under a type 1 hypervisor is the same architectural answer, reached with an open hypervisor that carries no product certificate at that layer. Whether a certified hypervisor or an open one is the right choice depends entirely on what the integrator has to prove and to whom.

Key takeaways

TÜV Rheinland certificate 968/FSP 1976.08/26 covers QNX Hypervisor for Safety as a Safety Element out of Context up to ASIL D, against ISO 26262-2, -6 and -8:2018. The type designation is the hypervisor; guest operating systems are not in it.
ISO 26262-9:2018, whose abstract names criteria for coexistence of elements and analysis of dependent failures, is absent from that standards list. Those analyses are item-level work that no component supplier can complete in advance.
A certificate with no expiry date still limits its coverage, through a dated revision list of software versions — 12 March 2026 for the hypervisor entry, 13 March 2026 for the QNX OS for Safety entry.
Certificate 968/FSP 2999.02/26 scopes one library in two pieces: C++ runtime components up to ASIL D, headers and templates up to ASIL B. Certificates describe parts of products, not products.
Stage-2 translation controls what software can name. Memory bandwidth, last-level cache, interconnect arbitration, thermal behaviour and shared accelerators are not controlled by it, and timing evidence measured with the Linux guest idle is not evidence about the shipped system.
For a passed-through device, the SMMU configuration is part of the freedom-from-interference argument, not a performance setting. It is configuration the integrator owns, not something a certified hypervisor settles.

Frequently asked questions

Does a certified hypervisor make the Linux guest safety-certified?
No. The type designation on certificate 968/FSP 1976.08/26 is QNX Hypervisor for Safety. Guest operating systems are not part of the certified product, and the certificate makes no statement about them.

Why does it matter that ISO 26262-9:2018 is not in the certificate's standards list?
Part 9 covers criteria for coexistence of elements and analysis of dependent failures, according to its ISO catalogue abstract. Those analyses depend on which elements are actually combined in the item, so they can only be performed by the integrator, not by the component supplier in advance.

The certificate says "no expiry date". Does that mean any version is covered?
No. The covered software versions are listed in a separate revision list that the manufacturer releases in cooperation with the certification body. The hypervisor entry's list is dated 12 March 2026, so moving to a build outside it is a change-impact question.

If a certified hypervisor partitions memory, why does the Linux guest's workload still affect timing in the safety domain?
Because the partition controls address spaces, not shared hardware. Both domains use the same memory controllers, caches, interconnect and thermal budget, so load in one can lengthen execution times in the other without any address-space violation occurring.

Is there a Linux equivalent of the ASIL D certificate held by QNX OS for Safety?
Not at that level in the public record checked for this post. The assessed Linux platform that exists is Red Hat In-Vehicle Operating System, certified as a Safety Element out of Context against ISO 26262 Edition 2, 2018 at Level ASIL-B, with exida as the assessor.

Secure Boot Key Custody: Who Holds the Signing Key?

Raghu Bharadwaj — Thu, 10 Sep 2026 05:28:53 +0000

Keep the production signing key off the build machine and reach it through a PKCS#11 token or an HSM, and run a separate development key that is never fused into a production part. The cost is that your continuous integration system can no longer produce a shippable image on its own. The gain is that a compromised build server does not become a compromised product line.

Secure boot key custody is the decision about where the private key that signs your firmware lives, and who can make it sign something. It is rarely decided deliberately, and usually settled when someone follows the vendor application note, runs the code signing tool against a directory of sample keys, and commits that directory so the next engineer can build. Months later the product ships, and the key that authorises every update sits in a shared repository.

The context

The hardware side is irreversible. On i.MX parts using HABv4 the public Super Root Keys form an SRK table, that table is hashed, and the hash is programmed into fuses. The Foundries.io i.MX reference states the consequence plainly: once programmed, those fuses cannot be modified. A further fuse, SEC_CONFIG[1], moves the part into the closed state, and a production device should also lock the SRK values. Other families use different names for the same arrangement, and none of them reopen a closed part.

The key also has to outlive the people and machines around it. A product with a ten-year field life needs a valid signature for ten years, while build servers get rebuilt and the engineer who made the key leaves. A key that exists only as a file on a machine has a shorter expected life than the product it authorises.

The third property is easy to miss. Secure boot key custody is one question repeated at each verification boundary, and the boundaries use different tools:

The boot ROM verifies the first-stage loader, using the vendor key tree and Code Signing Tool.
U-Boot verifies the FIT image holding the kernel and device tree, using a key whose public half sits in its control device tree.
The kernel verifies loadable modules, using the key named by CONFIG_MODULE_SIG_KEY.

Teams often protect the first key carefully and leave the other two in the build tree, which leaves a supported path to running an attacker's kernel on a device that reports secure boot as on.

The options

Option 1: key files in the source tree

The key pair is generated once and committed with the build metadata. In Yocto you point UBOOT_SIGN_KEYDIR at a directory in a layer, or set FIT_GENERATE_KEYS = "1" (the default is "0") so the build creates a pair when none exists.

# local.conf — development chain
UBOOT_SIGN_ENABLE = "1"
UBOOT_SIGN_KEYDIR = "${TOPDIR}/../keys/dev"
UBOOT_SIGN_KEYNAME = "dev"

Any engineer can build, bisect a boot regression and reproduce a customer's binary. Against that, the key is readable by anyone with repository access. Fused into shipping parts, it means the number of people who can sign your firmware equals the number who have ever had a checkout.

Option 2: key files on a restricted build server

The key stays out of version control on one machine, readable only by the release account. This is a real improvement for little work and keeps release signing automatic. Against that, the key is still an extractable file that anyone who can run a job on that machine can copy without leaving evidence.

Option 3: a PKCS#11 token or HSM the build calls

The private key is generated inside a smartcard, token or HSM and never leaves it: the build sends a hash and receives a signature. U-Boot's mkimage supports this through an OpenSSL engine:

raghu@techveda.org:~$ export MKIMAGE_SIGN_PIN=******
raghu@techveda.org:~$ ./tools/mkimage -F -N pkcs11 -r \
    -k "pkcs11:serial=000xxxxxxxxx;object=Signature%20key" \
    -K u-boot.dtb fitImage

-N pkcs11 selects the engine, -k supplies the token URL, -K writes the public key into U-Boot's control device tree, and -r marks it required, so U-Boot refuses a configuration it cannot verify.

The key is marked CKA_SENSITIVE and CKA_NEVER_EXTRACTABLE, so an attacker who compromises the build machine cannot leave with the ability to sign forever. They can still sign anything they like while access lasts, which is why this bounds the damage rather than preventing it. Against that, someone must own the token, its PIN and its backup, and a lost token with no spare key in the SRK table ends updates.

Option 4: a detached signing step after the build

The build produces an unsigned artefact and a small separate process signs it, which U-Boot supports because mkimage -F adds signatures to an existing FIT image. The component holding the key runs almost no code, and signing becomes an auditable event with a requester and an approver. Against that, it is the most work to set up.

The decision

For a product that will be closed in production, settle secure boot key custody as two key chains from the first week, and put the production key in hardware. The development chain uses option 1: keys in the repository, parts left open. Name that key dev and never fuse its hash into a part you sell. The production chain uses option 3 for the key material and option 4 for the process.

Two details matter. First, decide the key inventory before the first fuse is burnt. On i.MX the SRK table holds up to four public keys, and the SRK_REVOKE fuses cover only the first three, so a full table leaves one key that cannot be revoked as the fallback. A single-key table has no recovery path at all.

Second, U-Boot can require more than one signature. The required property on a key node accepts image or conf, and the /signature node accepts required-mode with the values any or all:

raghu@techveda.org:~$ fdtput -t s control.dtb /signature required-mode all

With any, a configuration signed by either of two required keys boots, which makes staged rotation possible: ship a release trusting old and new keys, then retire the old one. With all, both signatures are demanded, which supports two-person release control. That part of secure boot key custody is hard to change once devices ship.

The simpler options are sometimes right. If parts are never closed, the signature is a build convention rather than a control, so option 1 is proportionate and option 3 is unnecessary expense. If the team is two people and the alternative to committing a key is not shipping, commit the key, but record which fuse burn would make that permanent.

Custody protects the key; it says nothing about the correctness of the code that checks the signature. A verifier with a parsing flaw will accept an image the key never authorised.

The consequences of secure boot key custody

Secure boot key custody is easier to plan than to discover during a release.

Builds stop being self-contained. A signed release can no longer be reproduced from source alone, so the build documentation has to name who approves a signature. Development builds must stay reproducible or engineers cannot bisect.

The module key needs its own answer. The kernel build generates a key pair into certs/signing_key.pem when none is present, and setting CONFIG_MODULE_SIG_KEY to anything else disables that generation. It also accepts a PKCS#11 URI (RFC 7512). The kernel documentation is direct: the private key must be destroyed or moved to a secure location, not left in the source tree.

Verification is not one symbol. FIT verification needs CONFIG_FIT_SIGNATURE plus CONFIG_RSA or CONFIG_ECDSA, and U-Boot's documentation warns that CONFIG_LEGACY_IMAGE_FORMAT must stay disabled, because it offers a path around the check.

Key takeaways

Secure boot key custody is decided in practice by whoever produces the first signed image. Decide it before any fuse is programmed.
Run two chains: a development key in the repository for open parts, and a production key that is never a file.
A token or HSM converts a stolen key into temporary signing access.
Populate the whole SRK table before it is hashed into fuses, so revocation and rotation stay possible.

Frequently asked questions

Can we move the signing key into an HSM after the product has shipped?
You can move the key material only if it is still extractable. What you cannot change is which public key the parts in the field already trust, because that hash is in fuses. Settle secure boot key custody before the first production fuse burn.

Is a signed FIT image enough on its own?
No. U-Boot verifies the FIT image only if the public key is marked required in its control device tree, and only if U-Boot itself was verified by the stage before it. If the boot ROM does not authenticate the loader, an attacker replaces the loader and its trusted key together.

What happens to the signing token when the engineer holding it leaves?
A token in one person's drawer is a single point of failure with no backup. Either use an HSM with a documented operator model, or populate the whole SRK table so a lost key can be revoked.

Kernel & Embedded News: Arm64 Drops Big-Endian, Boots CPUs in Parallel

Raghu Bharadwaj — Tue, 08 Sep 2026 04:54:32 +0000

Arm64 platform direction dominated this week: Will Deacon posted v2 of the series that removes big-endian kernel support, aimed at Linux 7.4, and a new 19-patch series that brings parallel secondary CPU onlining to arm64 through the PSCI v0.2 CPU_ON argument. Alongside those, Linux 7.3-rc2 arrived unusually large with scheduler fixes among the corrections, Buildroot 2026.08 shipped with GCC 16 and glibc 2.44 support, and kernel.org published measurements showing AI crawlers consume about a fifth of its git infrastructure capacity.

The theme this week is direction-setting on arm64. Two of the five items come from the arm64 maintainer's own queue, posted on the same day, and both change what the platform will look like for the next decade: one removes a capability, the other modernises how arm64 machines with PSCI firmware boot. The remaining items cover the 7.3 stabilisation cycle, the embedded build-system cadence, and the infrastructure your git workflows depend on.

In this edition

Arm64 big-endian removal queued for Linux 7.4. Will Deacon's 14-patch v2 deletes the remaining big-endian kernel code; four maintainer acks are already in. — planning signal
Parallel CPU onlining through PSCI proposed for arm64. A 19-patch series wires arm64 into the generic HOTPLUG_PARALLEL machinery, with measured bringup-time cuts of 41 to 65 percent on the predecessor series. — long-term watch
Linux 7.3-rc2 is unusually large. The quiet week after the merge window did not happen; scheduler fixes for cache-aware load balancing on hybrid CPUs lead the pull. — test now
Buildroot 2026.08 released. Close to 1,000 changes: Linux 7.1.x headers, GCC 16.2.0 available, glibc 2.44, M68K nommu and IBM Power 10/11 support. — evaluate the upgrade
AI crawlers take a fifth of git.kernel.org capacity. First-party numbers from the kernel.org administrator: roughly 6 million daily requests, and only about 2 percent of traffic is legitimate. — workflow signal

Arm64 prepares to remove big-endian support

Will Deacon posted version two of "arm64: Remove unused big-endian support" on 7 September: 14 patches deleting roughly 540 lines of big-endian handling from the arm64 tree. The BPF JIT, the crypto assembly, the optimised string routines, the compat vDSO build, and the KVM hypervisor object all lose their big-endian paths, and every use of CONFIG_CPU_BIG_ENDIAN and __AARCH64EB__ under arch/arm64 goes away. The v2 series is rebased onto 7.3-rc1 and now forces little-endian explicitly during early boot.

This is the end of a staged process, not a sudden decision. CPU_BIG_ENDIAN was made to depend on BROKEN in 6.18, which made the code unbuildable in practice, and pieces of dead big-endian support have been leaving the tree since. The removal is planned for the 7.4 merge window, and the series already carries acks from Catalin Marinas, Arnd Bergmann, Eric Biggers and Marc Zyngier.

Two details matter for embedded teams. First, SETEND emulation for 32-bit user tasks stays, so mixed-endian 32-bit userspace continues to run. Second, in the review thread Arnd Bergmann confirmed the same process on 32-bit Arm: big-endian mode there is marked deprecated in 7.3, the ixp4xx platform has been repaired to run little-endian, and the arm32 removal is expected to wait one more long-term release.

We covered the pattern this belongs to in our 32-bit Arm deprecations edition: the kernel is systematically shedding configurations that have no testers. Big-endian arm64 hardware exists mostly in networking and telecom appliances built on vendor kernels; mainline effectively never had a big-endian arm64 user base, and code nobody boots is code nobody notices breaking.

How to check your device

A product that needs a big-endian arm64 kernel now has a fixed upper bound: kernel 7.3 and its stable series, and nothing after that. Check what you are actually running before assuming this does not affect you, because the configuration hides inside some vendor BSPs for network processors:

root@${MACHINE}:~# zcat /proc/config.gz | grep CPU_BIG_ENDIAN
# CONFIG_CPU_BIG_ENDIAN is not set

If that symbol is set on any of your targets, start the migration conversation with your silicon vendor now. The realistic paths are a little-endian port of the byte-order-sensitive code, or staying on a frozen kernel with a defined support end. For everyone else, this is a simplification: less conditional assembly in hot paths and one less configuration axis in the architecture you almost certainly ship.

Parallel CPU onlining through PSCI

The same day, Will Deacon posted "arm64: Implement parallel CPU onlining with PSCI v0.2+", a 19-patch series that lets arm64 bring its secondary CPUs into the kernel concurrently instead of strictly one after another. x86, MIPS and RISC-V already have parallel bringup; arm64 has been a holdout. The series supersedes the HOTPLUG_PARALLEL work posted by Jinjie Ruan of Huawei in June, and the cover letter credits his cooperation in reshaping it.

The mechanism is worth understanding. PSCI v0.2 gave the CPU_ON call a context argument that the firmware hands to the incoming CPU. The series uses it to pass each secondary CPU its boot parameters directly through firmware, which removes the serialisation point where every CPU had to identify itself against shared global state. With that in place, arm64 can drop its own custom secondary-CPU synchronisation and adopt the generic HOTPLUG_PARALLEL, HOTPLUG_SPLIT_STARTUP and core-sync machinery that the other architectures already use. The final patch hardens bringup against broken PSCI firmware, which is a realistic concern on shipping boards.

The performance claim comes from the predecessor series: Jinjie Ruan measured a 192-core HiSilicon server booting its CPUs in 8.6 seconds instead of 14.6, a 41 percent cut, with 62 to 65 percent cuts on 32-core and 64-core boards. There is a third benefit beyond code health and speed: inside a confidential guest, the new scheme protects against a malicious hypervisor that injects secondary CPUs into the guest after the onlining window has closed. Deacon presented the design at last year's KVM Forum, and the series is based on 7.3-rc2, so the earliest realistic merge target is 7.4.

What it means for product teams

CPU onlining is a visible slice of the boot budget on anything with many cores, and it lands entirely inside the window that fast-boot products care about: cold boot to service, and the reboot window during an A/B update. If your product has a boot-time requirement, put this series on the watch list and measure your current bringup phase — dmesg timestamps around the secondary CPU boot messages give you the number directly. Expect the gain to scale with core count, and expect the new path to stress PSCI implementations in vendor firmware that were only ever exercised serially. If you maintain a TF-A port, testing this series against it before it merges is exactly the kind of early report the arm64 maintainers are asking for.

7.3-rc2: the quiet week that was not

Linus Torvalds released 7.3-rc2 on 6 September and noted that rc2 is normally the calmest point of the cycle, whereas this one was, in his words, a "full fat" rc release. He added that nothing in it looks particularly odd, joking that everyone will blame AI for the volume either way. The fixes span filesystems, networking, BPF, a large DRM pull, and the EDAC updates that were forgotten during the merge window and pulled now. As covered in our 7.3-rc1 edition, this cycle merged the second-busiest merge window on record, so a large volume of fixes was predictable.

The scheduler pull is the part worth reading. 7.3 merged the flattened-runqueue rework of the fair scheduler's pick path; cache-aware load balancing, which groups related tasks onto cores sharing a last-level cache, has been in the kernel since 7.2. rc2's scheduler pull carries corrections in this area, and the notable one is from Intel engineer Tim Chen: cache-aware balancing could pull a task toward its preferred cache domain on a hybrid CPU even when the destination cores were too small for it, converting a cache-locality gain into a capacity loss. The fix vetoes such migrations on asymmetric systems, through both can_migrate_llc_task() and the active-balance path, and prioritises misfit migration over cache aggregation when the two conflict.

How to use it

The asymmetric-CPU corrections apply directly to big.LITTLE and DynamIQ embedded silicon, not only to desktop hybrid parts. If your workloads pin latency-sensitive threads on big cores and let the rest float, rc kernels are the right time to run your latency and throughput benchmarks and report regressions — after release, a scheduler behaviour change becomes your problem to bisect. Treat scheduler behaviour on 7.3 as unsettled until late in the rc series, and do not rely on scheduler benchmarks published against rc1 or rc2.

Buildroot 2026.08: the toolchain moves forward

Peter Korsgaard released Buildroot 2026.08 on 4 September, with close to 1,000 changes from 100 contributors. The toolchain updates are the most significant part in practice: support for Linux 7.1.x kernel headers, Binutils 2.46.1, GCC 16.2.0 available with the default moving to GCC 15, glibc 2.44, and uClibc-ng 1.0.59. Architecture support widens with M68K nommu and IBM Power 10/11 variants, and the release adds infrastructure for packages written in the Hare language, a virtual package for libudev, and SDL3 packages. On the removals side, defconfigs for the Acmesystems Aria and Arietta G25, Avnet S6LX9 MicroBoard, and Technologic TS-4900 and TS-5500 boards are gone.

The support arithmetic matters more than any single feature. 2026.08 receives fixes only until 2026.11.1 appears, which is roughly three months. Production products should either track every release deliberately or sit on the 2025.02.x LTS series, which is supported until March 2028. The compiler default moving to GCC 15, with GCC 16.2.0 selectable, is the kind of change to absorb in a controlled rebuild rather than during an unrelated bump — new compiler releases routinely surface latent warnings and subtle miscompilation reports in embedded code that has never seen them.

If you are following our Buildroot series, this release is a good live exercise: a BR2_EXTERNAL tree isolates your packages and board configs, so rebasing from 2026.05 to 2026.08 becomes a contained, testable step instead of a fork migration.

How to evaluate the upgrade

Rebuild your full image against 2026.08 in CI before committing to it. Read the CHANGES file specifically for your package set, confirm none of your boards depended on the removed defconfigs, and decide the GCC question explicitly — staying on the default GCC 15 or opting into 16.2.0 — rather than inheriting it. Teams on 2025.02.x LTS need no action beyond noting that the Buildroot Developers Meeting after ELCE in Prague is where the next LTS's direction gets discussed.

AI crawlers now cost git.kernel.org a fifth of its capacity

Konstantin Ryabitsev, who runs kernel.org's infrastructure, published first-party measurements of what AI scrapers cost the project. git.kernel.org receives about 6 million requests per day asking for individual commits rendered as web pages. The Anubis proof-of-work challenge stops 66 percent of them, but a third now solve the challenge and get through. With generous assumptions, legitimate use is about 2 percent of total traffic. Across the five geo-distributed nodes, 14 to 16 of 90 CPU cores do nothing but render commits as HTML for scrapers — around 20 percent of capacity on average, arriving in waves rather than as a steady load.

The detail that should annoy every engineer is the method. All of this data is available through a single git clone, in a form built for exactly this purpose: linux.git holds about 1.48 million commits, and even the mailing-list archives are clonable git repositories. Instead, the crawlers walk the web interface commit by commit — across roughly 922 forks of linux.git that mostly contain identical objects — through millions of short-lived residential and mobile proxy connections that defeat IP-based blocking. The consequence reaches you directly: kernel.org is reducing crawlable URLs and will gate expensive operations, so anonymous web access loses functionality. The data itself stays available to anyone who clones.

What it means for your workflow

Take this as the reason to make your own tooling both well-behaved and self-sufficient. Run an internal mirror for anything CI touches, and never point parallel CI jobs at kernel.org directly — the post singles out simultaneous shallow clones from many nodes as the load pattern that actually takes the service down. If any internal script fetches commits over the cgit web interface one URL at a time, convert it to operate on a local clone. Expect proof-of-work interstitials and reduced anonymous features on kernel.org web properties to become the norm, and budget a few seconds of challenge time into anything interactive.

References

— Raghu Bharadwaj

If you work on the Linux kernel or embedded Linux products, TECH VEDA runs instructor-led training on kernel internals, device drivers and BSP engineering — details at techveda.live.

Ten Years of Work Is Not Ten Years of Experience

Raghu Bharadwaj — Sun, 06 Sep 2026 09:02:35 +0000

Skill changes when you find out you were wrong. In engineering, whether you ever find out is decided by things you did not choose: how quickly the consequence appears, whether it reaches you at all, and whether anyone can still connect it to the decision that caused it. What a CV calls ten years of experience is a record of time spent present. It is not a record of how often the work corrected you, and those two numbers can be very far apart.

There is probably an engineer in your organisation with four years of experience who is plainly better than someone there with twelve. Not more confident, and not better in interviews — better at the work itself: quicker to the real cause, harder to surprise, right about the design more often than anyone else in the discussion. Everyone can see it. Nobody can quite explain it, so it gets put down to talent and is not examined further.

Talent is the least useful answer available, and it is usually not the correct one either.

The word doing the damage here is experience. Counted on a CV it means time present: you were employed, in that role, for that many years. Everywhere else we use it to mean something earned — that a person has been through things and is different as a result. The two meanings are quietly assumed to be the same, and years are counted as though the second follows automatically from the first. It does not follow, and the gap between the two is what the rest of this is about.

What actually changes you

Think about the last time your engineering judgement genuinely improved. It was almost certainly not the day somebody explained a concept to you. It was a day you were confident about something, acted on it, and discovered you had been wrong — and the discovery arrived close enough to the decision that you could still remember why you had made it.

That is the whole mechanism. A belief you held gets contradicted while you can still see the reasoning behind it. Nothing else does the same work. Reading does not, because reading adds facts without testing any of yours. Being told does not, unless you had committed to a position first.

Experience does not accumulate with time spent. It accumulates with contradictions received.

Which turns the question about experience into a question about arithmetic. Not how many years, but how many times in those years the work came back and told you that you were wrong.

The Tuesday

Here is how those occasions get lost, and it is not dramatic.

You decide, on a Tuesday, that a structure can be freed at the end of the callback. You think about it for under a minute, and everything you can see says you are right: the driver loads, the tests pass, the board runs for a week on the bench. The decision is wrong. Under a timing your bench does not produce, something is still holding a reference.

Eighteen months later, at a site in another country, units begin rebooting every few weeks. A support engineer collects a crash log. It sits in a queue. Eventually somebody looks at it properly, works out that a structure is being touched after it was freed, finds the path that does it, and fixes it in an afternoon. That engineer learns something real that day, and they learn it because they are the person who found out.

The loop did close. It closed for somebody else.

It never closed for you. Nobody told you, because by then there was no reason to connect the fix to you and no way to do it. And in those eighteen months you made the same kind of decision perhaps forty more times, at the same speed, with the same confidence, on the same evidence: nothing had ever come back to suggest you were getting it wrong.

Nothing about that story requires anyone to be careless. The bench was reasonable. The tests were reasonable. The support process worked exactly as designed. The decision still cost you the correction, and the correction went to a stranger. Eighteen months of experience were added to your CV. None were added to your judgement.

Why you cannot feel the difference

You might expect a missing correction to feel like missing information. It does not. There is no gap where it would have been, no reminder, nothing in the tree to grep for.

An unclosed loop does not feel like a gap in your learning. It feels like confirmation.

Worse, the effect is not evenly spread. It is worst exactly where you can least afford it. Small decisions are corrected constantly: a syntax error in seconds, a failed test in minutes, a review comment in a day. Large decisions are barely corrected at all, and the interface you chose or the layering you settled on may never report anything.

The quality of your feedback is inversely related to the importance of the decision it concerns.

So the confidence you carry about your own judgement has been assembled almost entirely out of the decisions that were easy to check. It feels like one continuous sense of competence, and it is not. It is reliable about syntax and largely untested about architecture.

This is also the answer to the question we started with. The engineer with four years was somewhere the loops closed quickly — a small team shipping often, a maintainer who reviewed strictly, a product whose failures came back within weeks and reached the person who caused them. Twelve years of specifying, handing over and moving to the next project delivers very few contradictions, and the person who lived through it has no way of knowing that is what happened. Those years were not wasted; exposure teaches a good deal on its own. But exposure without a returning signal produces familiarity rather than judgement, and it is very hard to tell those two apart in yourself.

Years accumulate on their own. Judgement only accumulates when the result reaches the decision that caused it.

Going to look for it

If the work will not reliably tell you when you were wrong, the remaining option is to go and find out on purpose. It is a disposition rather than a technique, and it shows up in three ordinary places.

Commit to a prediction before you look. Before the print, before the trace, before running the test: write down the value you expect and why. It costs ten seconds and it is uncomfortable, which is the point. A prediction you kept in your head will always seem correct afterwards, because you quietly adjust it to match what you found. A written one cannot be adjusted.
Go and find the consequences that were routed away from you. Read the support tickets for the products you have worked on, including the ones assigned to other people and the ones from two years ago. Almost nobody does this, because nothing requires it and it is not comfortable reading. It is the only way to see the results of decisions you have been repeating ever since you made them.
Notice how long it has been since you were proved wrong. Not corrected on a detail — proved wrong about something you were confident in. If you cannot remember the last occasion, the likely explanation is not that you have stopped being wrong.

It is also worth knowing what quietly lowers your rate. Moving into a role where you specify rather than build. Working on a product whose failures reach a support team instead of a developer. And, more recently, accepting generated output that works: you predicted nothing, so nothing was contradicted, and you end the day exactly as sure of yourself as you began it. This matters most where a wrong answer looks exactly like a right one until the timing changes.

The opposite is what makes an experienced colleague worth so much, and it has little to do with what they know. Their value is timing: they tell you the approach is wrong while you still remember the reasoning that produced it, which is the only moment at which being told changes anything. Months of delay become seconds.

So there is a question worth putting to yourself at the end of a year, and it is not whether you feel more capable than you did. Confidence will answer that one dishonestly. It is whether you can name three occasions when you found out you were wrong, and what you had to do to find out. If they come to mind easily, you gained a year of experience. If you have to search for them, you may only have gained a year, and silence is not the same thing as being right.

— Raghu Bharadwaj

I teach Linux kernel, device driver and embedded Linux courses at TECH VEDA. Sessions are live and mentor-led, built around working through problem scenarios — largely because that is the shortest feedback loop I know how to build.

Linux Kernel CVEs: What to Patch by Device (30 Aug - 5 Sep 2026)

Raghu Bharadwaj — Sat, 05 Sep 2026 16:57:14 +0000

Originally published on TECH VEDA: Linux Kernel CVEs: What to Patch by Device (30 Aug - 5 Sep 2026). This is a weekly series. Every CVE below was read from the CVE Program record, and the branch targets were checked against kernel.org.

The Linux kernel project published 188 Linux kernel CVEs in the week of 30 August to 5 September 2026. Every one of them is already fixed in a stable release. This week, no record marks a branch as affected without also naming a fixed version for it, so the branch update clears the whole set. None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing. The only action is to update to the fixed version for your branch. The minimum safe upstream release per branch is 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. One extra item this week: the 7.1 branch reached end of life with 7.1.13, so it will get no further fixes and needs a migration plan, not just an update.

188 records is close to a normal weekly volume for this project. Last week was 227, and that was unusual: a full stable cycle landed on one day and the records were published together. This week the count comes from ordinary weekly stable releases. The IDs form one continuous block, CVE-2026-80726 to CVE-2026-80913.

Most of these fixes are narrow. Which of these Linux kernel CVEs matter for you depends on what your product builds and how it is configured. A phone, an industrial gateway, a hypervisor host and a patient monitor build different code, so they are exposed to different parts of this list. The kernel CNA publishes no CVSS base score for most of these records, and NVD has not finished analysing the batch, so order your work by reachability and deployment context rather than by score. This advisory gives the version to install first, then explains which records matter for mobile and automotive, embedded and IoT, cloud and datacenter, and medical devices. Each record below has its own heading, so you can link straight to it.

The one action: update to the fixed version for your branch

Find the kernel version each product is running, compare it with the target for its branch in the table below, and update if it is lower. A system on 6.12.104, for example, is below the 6.12 target of 6.12.108 and needs the update.

Stable branch	Update to at least	Notes
5.10 LTS	5.10.269	Set by the three USB records that are fixed on every branch: `CVE-2026-80824`, `CVE-2026-80827` and `CVE-2026-80830`.
5.15 LTS	5.15.220	Set by the same three USB records.
6.1 LTS	6.1.187	Set by the same three USB records. This is also the lowest branch that names a fix for `CVE-2026-80852` (kTLS transmit offload).
6.6 LTS	6.6.156	Set by the same three USB records.
6.12 LTS	6.12.108	Set by the same three USB records. This release also carries `CVE-2026-80850` and `CVE-2026-80825`.
6.18 LTS	6.18.49	Set by the same three USB records. The futex and io_uring records are fixed earlier on this branch, in 6.18.47.
7.1 (end of life)	7.1.13	Set by the same three USB records. 7.1.13 clears every record below, but kernel.org marks it as the final 7.1 release, so this branch gets no further fixes.
7.2 stable	7.2.3	Set by the same three USB records. 7.2.3 is also the only release that fixes `CVE-2026-80853`, the SEV record.
mainline	7.3-rc1	The 7.3 merge window opened on 30 August 2026. 7.2, released 16 August 2026, is the current stable series.

Every target above is a release that already exists, so nothing here waits on a future stable release. Each of the eight stable targets is the newest release of its branch, so on an upstream kernel the check is simple: if you are not on the current release for your branch, you are behind. Three records set the target on all eight branches at once, and all three are in the USB stack: CVE-2026-80824 (use-after-free of the USB device structure when a usbfs file is closed), CVE-2026-80827 (out-of-bounds read in the USB serial option driver) and CVE-2026-80830 (a missing lock in the USB core wakeup notification path).

Branches not in the table were not named as affected by any record this week, or their fix was released before this window. The 6.19 and 7.0 series are not active stable branches.

The 7.1 branch reached end of life this week

This is the item to act on beyond the version bump. On 2 September 2026 the kernel project released 7.1.13 and marked the 7.1 branch as end of life. 7.1.13 contains the fixes for every record in this advisory, so installing it is still correct today. But no 7.1.14 will follow. From now on, every kernel CVE published against code that 7.1 contains will stay unfixed on 7.1.

If you ship 7.1, the update is not the whole job. Decide now where the product moves next. The two upstream options are 7.2, which is the current stable series and receives fixes weekly, and 6.18, which is a longterm branch with a much longer support window. A stable series such as 7.2 is supported only until the next one arrives, so if you want to change kernel version rarely, a longterm branch is the safer target. Plan the move through your normal validation process rather than as an emergency change, because 7.1.13 is fully patched as of this week and there is no time pressure.

Separately, mainline has moved on. The 7.3 merge window opened on 30 August 2026, so mainline now reports 7.3-rc1. That does not change anything you need to install; 7.2 is still the current stable series. It is listed here only so the mainline row in the table is not read as a release you should be running.

Last week's targets were 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12 and 7.2.2. Every branch has moved up exactly one point release since then. A system that was current after last week's advisory needs one more update.

One thing improved this week. Last week four records marked a branch as affected and named no fixed version for it, so the branch update did not clear them. This week there are no such records: all 188 name a fix for every branch they mark as affected. The four open items from last week are unchanged, however. CVE-2026-74752 (SCTP), CVE-2026-80551 (s390 vfio-ccw), CVE-2026-74743 (macvlan) and CVE-2026-80635 (wcn36xx Wi-Fi), plus CVE-2026-74582 from the week before, are still unfixed on the older LTS branches. Nothing in this window changes that, so if you track those five, keep tracking them.

If you run a vendor or BSP kernel, the version string will not compare cleanly with the table. A kernel that reports 6.6.60-imx is based on 6.6.60, and it will not become 6.6.156 by any upstream update you apply yourself. For those products the table tells you which fixes have to be present, not which release to install. Ask your silicon or BSP vendor to confirm, and treat a verified vendor backport as equivalent to the upstream target.

Mobile and automotive

Four records this week sit in code paths that matter on a phone, a tablet or a vehicle: Wi-Fi, Bluetooth, the CAN bus and the HDMI display path.

CVE-2026-80825: Wi-Fi mt7925 did not reserve transmit headroom for forwarded frames

The MediaTek mt7925 driver pushes a transmit descriptor and a USB header onto every outgoing frame, and assumes the headroom for them is already reserved. That holds for traffic the device generates itself, because mac80211 reserves hw->extra_tx_headroom. It does not hold for forwarded frames, which go out through ieee80211_8023_xmit() and do not get that reservation. The record shows the result directly: bridge a wired interface to an mt7925u access point, and the first short forwarded frame triggers skb_under_panic and a kernel BUG.

This matters wherever an mt7925 part is used as an access point or a bridge rather than as a plain client, which includes in-vehicle hotspots and tethering. The trigger is ordinary forwarded traffic, not a crafted frame. The fix reserves the headroom in the USB and SDIO transmit path. The affected file is drivers/net/wireless/mediatek/mt76/mt7925/mac.c, so the gate is CONFIG_MT7925U for the USB part and the SDIO build of the same driver. Fixed in 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80762: Bluetooth accept list use-after-free during suspend

When the system suspends, hci_update_event_filter_sync() walks the controller's accept list and sends a synchronous HCI command for each device allowed to wake the host. That walk holds hdev->req_lock, but accept-list updates are serialized by a different lock, hdev->lock. So while the code waits for the controller to answer, remove_device() can take the other lock, unlink the current entry and free it. When the wait finishes, the walk reads the freed entry. KASAN reports a use-after-free.

The window is the controller response time, which is long in kernel terms, so this is a race that can be hit in normal use on a device that suspends often. This is one of seven Bluetooth records this week; CVE-2026-80764 is a closely related use-after-free of the LE list on reset, and CVE-2026-80819 fixes missing locking in the RFCOMM deferred setup accept path. If you ship Bluetooth, take the branch update rather than picking single patches. The affected file is net/bluetooth/hci_sync.c, so the gate is CONFIG_BT. Fixed in 6.1.187, 6.6.156, 6.12.108, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80889: CAN ISO-TP timer and wakeup ordering

ISO-TP is the CAN transport protocol used for diagnostics and for any message longer than eight bytes, so it is present on most vehicle and heavy-equipment stacks. This record fixes four ordering problems in the socket code: a stale timer callback could re-arm another timer after a transfer was claimed, a sleeping sendmsg() could be left waiting after the socket was shut down, the wait loops did not wake on shutdown, and the shutdown path could be corrupted by a concurrent transfer claim.

Read the version data on this one carefully, because it is a follow-up. The record lists each branch as affected only from the point release two or three steps before the fix. On 5.10 the affected range is 5.10.265 to 5.10.267, on 6.1 it is 6.1.183 to 6.1.185, and so on. That means the bug was introduced by the previous CAN ISO-TP locking fix, not by old code. If you took that earlier CAN update, you need this one as well. If you are on an older release than that, this record does not apply to you, but the branch target still does. The affected file is net/can/isotp.c, so the gate is CONFIG_CAN_ISOTP. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.151, 6.12.103, 6.18.44 and 7.1.8. See the CVE record.

CVE-2026-80749: out-of-bounds read copying an HDMI audio infoframe

A helper copied an audio infoframe into the connector's stored copy using the size of the destination rather than the size of the source. The destination is a generic buffer sized to hold many different kinds of data block, so the copy read 60 bytes out of a 28-byte allocation. The fix uses the source size and adds a build-time check that the source is not larger than the destination.

Keep this one in proportion. It is a read, not a write, so it cannot corrupt memory, and the record says a real-world failure is unlikely; it was found running KUnit tests under KASAN. It is listed here because it is in the display sink path, which matters for infotainment and instrument-cluster designs that drive external HDMI sinks. The affected file is drivers/gpu/drm/display/drm_hdmi_state_helper.c, so the gate is CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER. Fixed in 6.12.105, 6.18.46 and 7.1.10. See the CVE record.

Embedded and IoT

Gateways, routers, single-board computers and battery-powered sensors are affected through the cellular modem driver, the NFC stack, the HID core and the in-kernel OpenVPN data path.

CVE-2026-80827: out-of-bounds read in the USB serial option driver

This is the record most embedded products should read first, because the option driver is what binds to almost every USB cellular modem. The driver sizes its interrupt buffer from the endpoint's wMaxPacketSize. If a device declares wMaxPacketSize = 8, the buffer comes from the 8-byte slab cache. When that device then sends a short packet, the completion handler still reads data[8], which is one byte past the end of an 8-byte allocation. That is a slab out-of-bounds read. The fix adds the missing bounds check.

The input is the attached modem, so the exposure depends on whether the modem is a fixed soldered part or a field-replaceable USB device. On a gateway with an accessible USB port, the attacker model is somebody plugging in a device. This record is also one of the three that set this week's target on every branch. The affected file is drivers/usb/serial/option.c, so the gate is CONFIG_USB_SERIAL_OPTION. Fixed in 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80795: out-of-bounds write in the NFC NCI target list

The NCI layer keeps discovered NFC targets in a fixed-size array. nci_target_auto_activated() appends a target and increments the counter without first checking whether the array is full. Its sibling function does check. The counter is only cleared by an explicit call, so an NFC controller that keeps re-running discovery and reporting an auto-activated target drives the counter past the array size. The append then writes a target structure past the end of the array. That is a slab out-of-bounds write, which is the more serious class of the two.

The input comes from the NFC controller, and the controller is driven by whatever tag or reader is held near the antenna. So the range is short, but no pairing or authentication is involved. The affected file is net/nfc/nci/ntf.c, so the gate is CONFIG_NFC_NCI. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80799: out-of-bounds read and offset wrap in the NFC LLCP parsers

The LLCP TLV parsers contain three related bugs. The loop offset is declared as an 8-bit value while the total length is 16-bit, so once the walk passes 255 the offset wraps to zero and the loop either repeats data or does not terminate. The type and length bytes are read without checking that two more bytes are available. And the value bytes are read without checking that the declared length fits in the buffer, so a declared length of 255 on a short buffer reads up to 255 bytes past the end.

This one is worth a note for anyone on an older LTS branch: the record lists the problem as reaching back to 5.10.188, 5.4.251 and 4.19.291, so it is long-standing code rather than a recent regression. Ten more NFC records land in the same week, the rest of the CVE-2026-80794 to CVE-2026-80803 block plus CVE-2026-80823, and they are all input validation in the same area. If your product has an NFC radio, treat the group as one update. The affected file is net/nfc/llcp_commands.c, so the gate is CONFIG_NFC. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80781: out-of-bounds read in the HID core

hid_set_field() passes field->usage + offset to the input dumping helper before the check that bounds offset. The usage array is allocated inline with the field structure and holds a fixed number of entries, so an offset past the end reads into a neighbouring object. Moving the bounds check ahead of the call fixes it, because the check already confines the offset to the array.

The reachability depends on one build option: the dumping helper only dereferences the pointer when CONFIG_DEBUG_FS is enabled. Production embedded images often build without debugfs, and those images are not exposed through this path. The affected file is drivers/hid/hid-core.c, so the gates are CONFIG_HID together with CONFIG_DEBUG_FS. This is one of 14 HID records this week, including CVE-2026-80780 (an out-of-bounds write when the device has no input) and CVE-2026-80783 (unbounded recursion parsing a Magic Mouse report). Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80735: ovpn dereferenced socket data it did not own

The in-kernel OpenVPN data channel stores its own state in the socket's sk_user_data field. Other subsystems use the same field for their own purposes. BPF SOCKMAP, for example, sets sk_user_data without setting the encapsulation type that ovpn uses to recognise its own sockets. So ovpn could dereference a pointer belonging to another subsystem, which gives out-of-bounds reads. The fix checks the encapsulation type before the dereference.

This is narrow but relevant on gateways that terminate VPN tunnels and also run BPF programs on sockets, which is a common combination on modern edge routers. The ovpn driver was merged in 6.16, so the older LTS branches do not contain this code at all. The affected file is drivers/net/ovpn/socket.c, so the gate is CONFIG_OVPN. Fixed in 6.18.45 and 7.1.9. See the CVE record.

Cloud and datacenter

The highest priority here is the NVMe-over-TCP target, because the input arrives from the network before authentication. The guest-to-host records come next, then the local memory-corruption records that matter on shared hosts.

CVE-2026-80789: NVMe-over-TCP target allocated buffers from an unbounded wire value

The target reads the 32-bit SGL length sent by the initiator. For the in-capsule descriptor type it checks that length against the configured inline data size. For every other descriptor type, including the transport data-block descriptor that a real initiator uses for out-of-capsule writes, the check is skipped and the value goes straight into the scatterlist allocator. The value is host-controlled and unbounded up to 4 GiB, and no other layer inspects it. The fix bounds the length before the allocation.

Treat this as the first item on any host that exports NVMe-over-TCP namespaces, because the trigger is a single command from anything that can open a TCP connection to the target port. The companion record CVE-2026-80788 covers the same code path from the other side: an oversized SGL made the page allocator hit a warning that a remote initiator could trigger at will, and that warning is now removed. The affected file is drivers/nvme/target/tcp.c, so the gate is CONFIG_NVME_TARGET_TCP. Fixed in 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80891: KVM on s390 pinned guest pages without validating the interrupt vectors

For PCI passthrough on s390, the host pins guest pages that hold the adapter interrupt bit vector and the summary bit indicator. The size of the bit vector is derived from values the guest supplies. Neither the size nor the alignment was validated, so a bit vector spanning more than one page, or a summary address that is not 8-byte aligned, could be accepted and pinned. The fix rejects both cases.

This crosses the guest-to-host boundary, which is why it belongs at the top of the list on any s390 host that passes PCI functions through to guests. The affected file is arch/s390/kvm/pci.c, so the gate is CONFIG_KVM on s390 together with zPCI passthrough enabled. Fixed in 6.1.183, 6.6.151, 6.12.103, 6.18.44 and 7.1.8. See the CVE record.

CVE-2026-80853: KVM SEV used a partial page as a firmware command buffer

When KVM encrypts or decrypts guest memory through a temporary buffer, the page holding that buffer is handed to SEV firmware for the duration of the command. On an SNP-enabled host, a page assigned to firmware must be wholly owned by KVM, because other kernel code sharing the same page could be allocated and accessed while the transfer of ownership is in effect. The buffer was smaller than a page, so the rest of the page was not KVM's. The fix allocates a full 4 KiB page.

This is the one record in this advisory that affects a single branch. It is fixed in 7.2.3, and no other stable branch is named as affected. It matters for confidential-computing hosts that run SEV or SEV-ES guests on SNP-capable hardware. The affected file is arch/x86/kvm/svm/sev.c, so the gate is CONFIG_KVM_AMD_SEV. See the CVE record.

CVE-2026-80758: use-after-free in the futex private hash

The futex code drops its reference to the private hash and then reads a field out of that same structure. Dropping the reference re-enables preemption. If that drop released the last reference and the task is then preempted, another task can switch to the replacement hash and free the old one after a grace period. When the first task resumes, it reads from freed memory. KASAN reports a use-after-free read in a freed 512-byte allocation. The fix loads the field while the reference is still held.

Futex code is reachable by any unprivileged process, and it is built on every normal configuration; turning it off requires an expert-mode kernel config. That makes this the widest-reaching local record of the week, and it is the one to prioritise on multi-tenant hosts and container fleets. Four more futex records land in the same week: CVE-2026-80775 is a race on the initial private-hash allocation and CVE-2026-80776 is a race during the private-hash resize, and CVE-2026-80777 and CVE-2026-80778 fix ownership handling across exec() and across address spaces. The affected file is kernel/futex/core.c. Fixed in 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80810: io_uring computed a folio size with a 32-bit shift

When filling the bio vector for a registered buffer, io_uring computed the folio size as 1 << imu->folio_shift using a plain int for the 1. The shift count comes from the folio backing the buffer and can be 32 or more on a 64-bit kernel. Shifting a 32-bit value that far is undefined behaviour, and on x86 and arm64 the processor takes the count modulo 32, so a shift of 34 produces 4 instead of 16 GiB. The size estimate and the fill loop then disagree about how many segments are needed. The fix uses an unsigned long, as the rest of the file already does.

The precondition is a registered buffer backed by a very large folio, which in practice means a host configured for 1 GiB pages or larger. That is a deliberate configuration, not a default, so most systems are not exposed. On hosts that do use huge folios with io_uring, an unprivileged process can reach it. A second io_uring record this week, CVE-2026-80811, fixes an iovec leak in the io_uring command path. The affected file is io_uring/rsrc.c, so the gate is CONFIG_IO_URING. Fixed in 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80850: use-after-free of TCP-AO state on connect

TCP Authentication Option protects long-lived TCP sessions, and it is most often used on BGP peerings. On connect, the socket is added to the lookup hash before the AO key state is initialised. The connect path first checks that a key matches the peer and the bound device's VRF membership, then resolves the VRF again later and removes keys that do not match. The socket lock does not stop the device from being detached from its VRF in between. If that happens, the first check passes, the second observes a different VRF and removes the only key, and the no-key path then frees the AO state on a socket that is already visible in the hash. The fix keeps the two views consistent.

The trigger requires a VRF change during connect, so this is a race rather than something a remote peer can drive on its own. It is listed here because the affected deployments are network devices and routing hosts that use both VRFs and TCP-AO. The affected file is net/ipv4/tcp_ao.c, so the gate is CONFIG_TCP_AO. Fixed in 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80852: out-of-bounds write in the kTLS transmit offload path

The kTLS device path checks whether an open record still has room for another fragment only at the bottom of its loop, and the MSG_MORE early exit skips that check. The record then survives into the next system call with the fragment count it already had, and the append function does not check either. With transmit zero-copy enabled, repeated splice() calls with SPLICE_F_MORE each add a fragment that cannot be merged, and the fragment count grows past the end of the fixed-size fragment array in the record structure. That is an out-of-bounds write. The fix adds the missing checks.

The precondition is real hardware TLS transmit offload. The record notes it was found with a network device simulator, because the code path is otherwise only reachable on a NIC that implements the offload. So this matters on datacenter hosts with kTLS offload enabled on the NIC, and nowhere else. The affected file is net/tls/tls_device.c, so the gate is CONFIG_TLS_DEVICE. Fixed in 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

Medical devices

Several of this week's records are worth reviewing for connected clinical equipment, and they fall into three groups.

Wireless and short-range links. CVE-2026-80762 matters for wearables, patient monitors and any device that suspends and wakes on a Bluetooth link, and the other six Bluetooth records this week are in the same connection-lifetime area. CVE-2026-80795 and CVE-2026-80799 matter for equipment that reads NFC tags, which includes patient wristband readers and consumable authentication on infusion and dialysis equipment.
Network protocols. Devices that carry DICOM, HL7 or FHIR over IP should review CVE-2026-80850 if they use TCP Authentication Option, and should note that CVE-2026-74752 in SCTP, carried over from last week, is still unfixed on every LTS branch below 7.1. Devices that reach the network through a USB cellular modem should review CVE-2026-80827.
Bedside peripherals. CVE-2026-80781 in the HID core, and the 13 other HID records this week, apply to any device with an attached keyboard, barcode scanner, pointing device or foot pedal. Check whether your image builds CONFIG_DEBUG_FS, because that decides whether this particular record is reachable at all.

Patching a medical device is not the same as patching a server. The update has to pass validation and regulatory revalidation, under the US FDA postmarket cybersecurity guidance, the EU Medical Device Regulation (MDR) and IEC 62304. So the action is to plan the stable kernel update through the manufacturer's change-control process, and not to apply it outside that process.

How to check which Linux kernel CVEs apply to you

There are three questions.

First, version. Compare the running kernel version with the table above. Because this week's targets are the newest release on every branch, the check is simple: if you are not on the current release for your branch, you are behind. Unlike last week, the branch target is the whole answer this time, because no record leaves a branch affected and unfixed.

Second, configuration. Check your kernel config for the feature behind each record. If the vulnerable code is not built into the kernel and is not available as a loadable module, the record is generally not reachable through that feature. On a running system with config access enabled, one command covers the most widely built of them.

raghu@techveda.org:~$ zcat /proc/config.gz | grep -E '^(# )?CONFIG_(BT|NFC|HID|IO_URING|TLS_DEVICE|USB_SERIAL_OPTION)[ =]'
CONFIG_BT=m
CONFIG_NFC=m
CONFIG_HID=y
CONFIG_IO_URING=y
# CONFIG_TLS_DEVICE is not set
CONFIG_USB_SERIAL_OPTION=m

The pattern is anchored on purpose. A plain grep CONFIG_BT would also match CONFIG_BTRFS_FS and every CONFIG_BT_* sub-option, which makes the output hard to read. The other symbols used in this advisory are CONFIG_MT7925U, CONFIG_CAN_ISOTP, CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER, CONFIG_NFC_NCI, CONFIG_DEBUG_FS, CONFIG_OVPN, CONFIG_NVME_TARGET_TCP, CONFIG_KVM, CONFIG_KVM_AMD_SEV and CONFIG_TCP_AO.

Read =m differently from =y. A symbol set to m means the code is present on the system and can be loaded, so it still counts as reachable unless your module-loading policy prevents it. If your system has no /proc/config.gz, use the config file from your build tree or the matching file under /boot. One record in this advisory, CVE-2026-80758 in futex, has no practical config gate at all, because futex support is built on every normal configuration.

Third, reachability, which sets the order of work. The records describe code paths rather than attacker models, so the ordering below is our reading of reachability and not a statement from the kernel CVE team.

Remote and over-the-air paths come first. On a storage host, that means CVE-2026-80789 in the NVMe-over-TCP target, because a single command from any client that can reach the port triggers it. On a device with a radio, that means the NFC records and the Bluetooth records. Local unprivileged memory corruption comes second, led by CVE-2026-80758 in futex, which is reachable by any process on almost any configuration. Guest-to-host records come third and are first in priority on shared hosts: CVE-2026-80891 on s390 and CVE-2026-80853 on SEV hardware. Records that need a specific configuration or specific hardware come last, which is where CVE-2026-80852, CVE-2026-80810 and CVE-2026-80749 sit.

Key takeaways

Update to the target release for your branch: 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. Each target is the newest release of its branch.
The 7.1 branch reached end of life with 7.1.13 on 2 September 2026. Install 7.1.13, then plan a move to 7.2 or to a longterm branch such as 6.18, because no further 7.1 release will come.
Unlike last week, the branch update clears everything published in this window. No record this week marks a branch as affected without naming a fix for it.
Three USB records set the target on all eight branches: CVE-2026-80824, CVE-2026-80827 and CVE-2026-80830.
Five older items are still open on the older LTS branches: CVE-2026-74752, CVE-2026-80551, CVE-2026-74743, CVE-2026-80635 and CVE-2026-74582. Nothing this week changes them, so keep tracking them separately.
On a storage host, schedule CVE-2026-80789 first. The NVMe-over-TCP target allocated buffers from an unbounded value sent by the initiator.
On a multi-tenant or container host, schedule CVE-2026-80758 first. Futex code is reachable by any unprivileged process and is built on every normal configuration.
On a device with a radio, the NFC group (eleven records this week) and the Bluetooth group (seven records) are the ones to take as a unit rather than as single patches.
On a vendor or BSP kernel, ask the vendor to confirm the fixes are in their tree rather than comparing version strings.
None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing. That is a point-in-time check, not a guarantee.

Frequently asked questions

What is the one thing I should do?
Update to the target release for your branch: 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. Each of those is the newest release of its branch, so on an upstream kernel you just install the current release. If you run a vendor or BSP kernel, ask your vendor to confirm the fixes are in their tree instead, because a vendor version string will not compare cleanly with those numbers.

I run 7.1. What does its end of life mean for me?
7.1.13, released on 2 September 2026, is the final release of the 7.1 branch. It contains the fixes for every record in this advisory, so installing it is still the right action today. But no 7.1.14 will follow, so from now on kernel CVEs affecting code that 7.1 contains will stay unfixed on that branch. Install 7.1.13, then plan a move to 7.2, which is the current stable series, or to a longterm branch such as 6.18 if you would rather change kernel version rarely. There is no time pressure this week, because 7.1.13 is fully patched.

Is 188 CVEs in one week a lot?
No, it is close to a normal week for this project. Last week was 227, and that was unusual because a full stable cycle landed on a single day and all the records were published together. This week the count comes from ordinary weekly stable releases. The IDs form one continuous block, CVE-2026-80726 to CVE-2026-80913.

Are any of these a 0-day?
No. All 188 were published with fixes already in stable, and this week every record names a fixed version for every branch it marks as affected. None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing, though that is a point-in-time check rather than a guarantee. The action is to schedule the stable update through your normal process.

I already applied last week's targets. Am I covered?
No. Last week's targets were 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12 and 7.2.2. Every branch has moved up exactly one point release since then, so you need this week's targets as well. Three USB records, CVE-2026-80824, CVE-2026-80827 and CVE-2026-80830, are the reason the target moved on every branch.

Which one should I schedule first?
It depends on what the machine does. On a host that exports NVMe-over-TCP namespaces, CVE-2026-80789, because the input arrives from the network before authentication. On a multi-tenant or container host, CVE-2026-80758 in futex, because any unprivileged process can reach it. On an s390 host with PCI passthrough, CVE-2026-80891. On a device with an NFC or Bluetooth radio, the NFC group and the Bluetooth group. On a gateway with a USB cellular modem, CVE-2026-80827.

We do not build NFC, Bluetooth or NVMe-over-TCP. Do these affect us?
Each bug is gated by a kernel config option, and the ones used in this advisory are CONFIG_MT7925U, CONFIG_BT, CONFIG_CAN_ISOTP, CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER, CONFIG_USB_SERIAL_OPTION, CONFIG_NFC_NCI, CONFIG_NFC, CONFIG_HID with CONFIG_DEBUG_FS, CONFIG_OVPN, CONFIG_NVME_TARGET_TCP, CONFIG_KVM, CONFIG_KVM_AMD_SEV, CONFIG_IO_URING, CONFIG_TCP_AO and CONFIG_TLS_DEVICE. If the vulnerable code is not built into the kernel and is not available as a loadable module, the record is generally not reachable through that feature. Read a symbol set to m as still present and loadable rather than absent. One record is an exception: CVE-2026-80758 in futex has no practical config gate, because futex support is built on every normal configuration.

Why did only some records get their own heading?
188 records is too many to explain one by one, so this advisory explains the ones that are reachable over the air, reachable by an unprivileged local process, or reachable across the guest-to-host boundary, plus a few that are tied to a specific device class. Every record in the window is fixed by the branch target in the table, so the ones without a heading are covered by the same single update.

What a Linux Safety Certification Actually Covers

Raghu Bharadwaj — Fri, 04 Sep 2026 03:51:46 +0000

A Linux safety certification is a statement about one defined software configuration running on named hardware, assessed by a named body. It is not a statement about the Linux kernel, and it does not give your item its integrity level. The document describing how a component like the kernel enters an ISO 26262 argument at all is ISO/PAS 8926:2024, published on 29 January 2024, which moves the question away from code quality and towards classification, complexity and evidence. Red Hat's In-Vehicle Operating System is the clearest public example: certified by exida against ISO 26262 Edition 2 (2018) as a Safety Element out of Context at ASIL-B, with Renesas naming the R-Car S4 as the first platform to be certified.

If you build vehicle software on Linux, a supplier will at some point hand you a claim that sounds decisive: this platform is certified. The engineer who has to integrate it then finds the claim carries almost no information on its own. A Linux safety certification is bounded by a configuration, a set of assumptions, a hardware list and an assessor. This article explains where those bounds come from, what changed in 2024, and what to ask before accepting such a claim into your own safety case.

Why the kernel cannot be qualified

Functional safety standards assume a particular kind of software. A classic safety component is written against a complete requirements specification, each requirement traced to a design element, to code and to a test, with structural coverage evidence at the end. That is workable for tens of thousands of lines written by one team for one purpose. The Linux kernel is not that: tens of millions of lines, contributed by thousands of people who never wrote a requirements specification for the automotive context, changing on a nine-week cadence.

An earlier article here, Safety-Critical Linux: What Certifying It Actually Takes, sets out how a safety argument is assembled around Linux. This goes a level below it: by what defined mechanism does pre-existing software become admissible in an ISO 26262 argument at all, and what does the resulting certificate bound?

Before 2024 there was no route designed for this, which is why a Linux safety certification was so hard to scope. The two normally reached for are both in ISO 26262-8:2018, the supporting-processes part: qualification of software components, and the proven-in-use argument. Qualification expects the component's functional behaviour, resource usage and behaviour under failure and overload to be specified and tested, which is impractical across the number of interfaces a kernel exposes. Proven in use expects field evidence about an unchanged element, which does not fit a codebase that takes fixes continuously.

What ISO/PAS 8926:2024 adds to a Linux safety certification

ISO/PAS 8926:2024 is titled Road vehicles — Functional safety — Use of pre-existing software architectural elements. Published on 29 January 2024, 19 pages, from ISO/TC 22/SC 32, the subcommittee that produces ISO 26262. It is a Publicly Available Specification rather than an International Standard, so it is a published route to a Linux safety certification rather than an obligation, and whether a programme uses it is a matter for its safety plan and its assessor.

It defines a term for the thing you are trying to bring in. A pre-existing software architectural element, abbreviated PSAE, is software that already exists — commercial off the shelf or custom — that was not built to order and was not developed to conform with the ISO 26262:2018 series. The Linux kernel meets that definition, as do the C library and a vendor BSP's driver set. Meeting it is a starting condition, not a verdict: an element becomes safety-related only when software safety requirements are allocated to it, or when its failures could violate one.

One of the two elements the specification illustrates is an operating system. Its general clause describes an OS hosting safety-related applications and names the properties such an element can carry: correct execution with partitioning to achieve freedom from interference, and a defined strategy for fault handling. The other illustration is a safety-related device driver. That first one tells you what a Linux safety certification is about — not that the kernel is correct, but that this configuration provides partitioning and fault handling adequate to the requirements allocated to it.

That sentence is easy to read too generously. Naming partitioning as a property of an operating system is not the same as a stock kernel supplying it. Freedom from interference has to be argued for the specific resources the safety function uses, and the mechanisms are mostly not kernel defaults: memory and device isolation through the MMU and the IOMMU, a hypervisor or a separate safety island, CPU affinity and cpuset reservation, interrupt affinity, explicit device assignment, and watchdogs with defined restart domains and safe states. Each of those has to be configured deliberately and then shown to hold. The residual paths are where the argument is usually lost rather than won: a DMA-capable peripheral reaching memory it should not, cache and memory-bandwidth contention between a safety task and an infotainment workload, a shared clock or reset domain, or a driver shared across the partition boundary. Enabling an isolation feature is the start of the argument, not the argument.

The examination of a pre-existing element covers, among other things:

which of the element's functions and properties correspond to the safety requirements allocated to it;
whether its implementation and interfaces fit the static and dynamic design of the target architecture;
whether the target has enough hardware and software resources once it is integrated;
whether unused functionality can be shown not to interfere, or excluded — the specification names build-process configuration settings as the way this is done;
whether unintended behaviour is absent, or the risk it introduces is low enough.

The fourth changes daily work. A kernel configuration here is not a build preference; it is the evidence for what was built into the image and what was left out. Note the limit: not compiled in is not the same as absent from the running system. Anything set to m still ships and can be loaded, and options pulled in by select arrive without being asked for.

Classification, complexity and evidence

The mechanism ISO/PAS 8926 adds on top of ISO 26262-8, and the one that decides the shape of a Linux safety certification, is a classification step. It decides whether software qualification under ISO 26262-8:2018, Clause 12 applies to the element, or whether specific safety activities are tailored under ISO 26262-2:2018, 6.4.5.1 and 6.4.5.2, and planned under 6.4.6.7. Confirmation measures under 6.4.9 may apply to the classification and impact analysis themselves. Those cross-references are cited by number inside the specification.

Two considerations drive the classification. The first is that uncertainty about the process used to develop the element may increase the likelihood of systematic faults. The second is that the element's complexity can make systematic faults harder to find. Complexity is then evaluated with selected measures, and the specification allows numerical methods such as cyclomatic complexity or a count of lines, as well as qualitative methods.

Applied to the kernel, this determines what a Linux safety certification can claim. Complexity is an explicit acceptance input, so the way to make the argument tractable is to reduce the element rather than defend it: the smallest configuration that still supports the allocated requirements. A line count is only an input, and not the one that dominates — configuration choices, concurrency, and the number of interfaces exposed through system calls, ioctls and sysfs matter more to a Linux platform than any single number. The practical work is configuration reduction, interface analysis and exclusion of unused subsystems, not kernel code review.

The specification also defines provenance — the origins, custody and ownership of the software and its data — which for a kernel arriving as a vendor BSP branch on a stable series on mainline means which tree, which tag, which patches, and who applied them. The route has an entry condition too: it assumes a software safety requirements specification, a safety analysis report and organisation-level functional-safety processes already exist. A BSP team cannot start here.

One limit, stated plainly: the classification criteria, the class boundary, the suitability evaluation and both annexes are in the paid text and were not read for this article.

What changed, and when

State	Date	Position	Source
Before	17 December 2018	ISO 26262-8:2018 published, Edition 2, 60 pages. The routes for a pre-existing element are software-component qualification and the proven-in-use argument. Neither is designed for the kernel's size or change rate.	ISO catalogue entry 68390
After	29 January 2024	ISO/PAS 8926:2024 published, Edition 1, 19 pages, same subcommittee. Adds a classification step deciding whether Clause 12 qualification applies at all, or the ISO 26262-2 activities are tailored instead, and makes complexity an explicit input.	ISO catalogue entry 83346
Since	8 July 2024	ISO 26262-8:2018 moved to stage 90.92, "International Standard to be revised". ISO's catalogue names ISO/DIS 26262-8 as under development.	ISO catalogue entry 68390

The last row indicates where the standard is heading, and should be read carefully rather than optimistically. A part moving to "to be revised" tells you the committee intends a new edition. It does not tell you what that edition will say, and no publication date was found. Planning a programme around a future Part 8 means planning around something that does not exist yet.

Reading a Linux safety certification claim

The clearest public example of a scoped claim is Red Hat's. In a press release dated 20 May 2025, Red Hat states that Red Hat In-Vehicle Operating System achieved functional safety certification as a Safety Element out of Context against ISO 26262 Edition 2, 2018, at ASIL-B, assessed by exida. The same release says customers will receive a Safety Guidance document containing Assumptions of Use, and that qualified hardware platforms will be rolled out on a cadence within the scope of the certification, with Renesas stating that the first certification will be on the R-Car S4. Those were forward-looking statements in May 2025. This article did not read the exida certificate or any assessment report and found no later dated statement, so which platforms are in scope today is not established here.

Almost all of that is scope: a named product rather than "Linux", a named assessor, a named standard and level, and a hardware list that grows over time, so the certificate covers the silicon on that list and not the silicon you happen to have. That gives a repeatable test. For any Linux safety certification claim, ask these six questions, and ask for the artefact in the third column rather than accepting the answer in prose.

Ask the supplier	Why it matters	Evidence to request
What exactly is certified?	A distribution, one configuration of it, and one component within it are three different claims. "Linux" is not a uniquely identifiable deliverable.	Release identifier, kernel tree and commit, patch manifest, the shipped configuration, image hashes
Who assessed it, against which standard, edition and level?	An assessment without a named body is a self-declaration. Edition and integrity level change what the claim means.	Certificate or assessment statement, with scope wording, issue date and current status
On what hardware?	An out-of-context assessment is bound to assumed context, and the target platform is part of that context.	Qualified-platform list, SoC and board revisions, errata assumptions
What are the Assumptions of Use?	These are obligations transferred to you. Unmet assumptions do not weaken the certificate; they put your system outside its scope.	Safety manual or safety guidance document, integration constraints, confirmation measures
What is explicitly outside scope?	Exclusions are where an assumed use case quietly stops being covered.	Stated exclusions, unsupported drivers and features, interface limitations
How are updates handled?	Security and maintenance changes can move the delivered software outside the assessed baseline.	Patch policy, impact-analysis criteria, notification terms, re-assessment conditions

Two things a Linux safety certification does not do are worth stating. It does not transfer an integrity level to your item: an out-of-context element is assessed against an assumed ASIL, while the level your item needs comes from your own hazard analysis. And ISO 26262 does not require third-party certification at all. What it requires is a functional safety assessment and confirmation measures, so a supplier delivering a safety case with an independent assessment and no certificate can be entirely conformant.

Three claims are also used interchangeably when they are not the same, and only one of them is a Linux safety certification. Certified means an assessment happened and a certificate names a scope. Certifiable means a package exists to support an assessment you must still arrange. A safety package is available means documentation exists and no assessment has been stated. All three can be legitimate; only the first carries an assessor's name.

A certificate does not freeze the baseline

The awkward part of a Linux safety certification is that the certified thing keeps moving. Security fixes arrive, the vendor rebases, the toolchain is updated, a board revision changes. None of that is prohibited, and none of it is free: each change needs an impact analysis against the certified scope, the Assumptions of Use and the evidence set, and the depth of re-verification that follows depends on the change and on the safety plan. ISO/PAS 8926 carries a clause on changes to the element's design, whose content sits in the paid text.

The practical consequence is that a Linux safety certification is a baseline under control, not a baseline frozen. A programme that cannot say which patches it has taken since the assessed release, and what each one touched, has lost the thread of its own argument regardless of what the certificate says. This is the same problem as provenance, seen from the maintenance end.

What ELISA does, and what it does not

The Linux Foundation's ELISA project — Enabling Linux In Safety Applications — is where much of the shared groundwork happens. Its site lists eight working groups: Aerospace, Automotive, Linux Features for Safety-Critical Systems, Medical Devices, Open-Source Engineering Process, Safety Architecture, Systems, and Tools. It publishes tooling openly, including BASIL and ks-nav.

Its position on certification is worth stating because it is often assumed to be otherwise. In the write-up of the ELISA Workshop held at Canonical's London office from 9 to 11 June 2026, published on 27 August 2026, the project records that its Ask Me Anything session clarified that ELISA does not certify Linux and does not guarantee the safety of a complete product. Its role is to identify gaps and develop approaches organisations apply in their own certification contexts, so an appeal to ELISA membership is not a Linux safety certification claim, and using its tools is not evidence until they have a defined role in your safety plan.

What it does produce is dated and readable. The Linux Features for Safety-Critical Systems working group gave its annual update on 11 February 2026, presented by Alessandro Carminati of NVIDIA. Its 2025 work included a minimal Linux footprint — tracing real application behaviour to determine which kernel features are actually used — and memory isolation analysed through the lifecycle of Virtual Memory Areas. Both bear directly on the exclusion and freedom-from-interference arguments above, and both are investigative rather than a safety case. The workshop slides are published, and the next scheduled event is the Safe Systems with Linux microconference at Linux Plumbers in Prague, 5 to 7 October 2026.

What this means for the engineer holding the BSP

Three obligations follow from the classification and examination requirements, and a Linux safety certification will eventually ask you to produce all three.

The first is configuration identity: the configuration of the kernel that shipped, taken from the device rather than your build directory. Where the defconfig sets CONFIG_IKCONFIG_PROC, it is embedded in the kernel and readable at runtime:

root@s32g399aevb3:~# uname -r
root@s32g399aevb3:~# zcat /proc/config.gz > /root/running.config
root@s32g399aevb3:~# grep -E "^(# )?CONFIG_(PREEMPT|LOCALVERSION|MODULE)" /root/running.config

The pattern is anchored so it returns the whole CONFIG_MODULE family and not only the plural CONFIG_MODULES, and the # CONFIG_x is not set lines matter as much as the rest. This works on the NXP S32 automotive BSP because s32cc_defconfig sets CONFIG_IKCONFIG_PROC=y; not every vendor defconfig does. Given only a delivered image and no board, scripts/extract-ikconfig recovers the same data from the kernel binary.

The second is provenance and drift. Back on the build machine:

raghu@techveda.org:~$ git -C linux config --get remote.origin.url
raghu@techveda.org:~$ git -C linux describe --long --tags --always --dirty
raghu@techveda.org:~$ git -C linux log --oneline v6.12.92..HEAD
raghu@techveda.org:~$ scp root@s32g399aevb3:/root/running.config .
raghu@techveda.org:~$ linux/scripts/diffconfig running.config linux/.config

The first three establish which tree, which tag and which patches sit above the stable base. --tags is needed because a lightweight vendor tag is otherwise ignored, and --dirty because uncommitted patches are otherwise invisible. The last compares what shipped against what you think shipped. Empty output is the evidence, and only the output: diffconfig exits zero whether or not it finds a difference, and also when it cannot open a file. Treat it as an early drift check rather than proof of equivalence — it compares Kconfig symbols, so it says nothing about the compiler, the device tree, the modules or the image, and it ignores the version banner, which is why uname -r comes first on the board. For an out-of-tree or Yocto build the configuration is in the build directory, and the layer revisions matter as much as the kernel commit.

The third is the exclusion argument. Every subsystem, driver and feature built in but not required by the safety function is something you will be asked to justify, and under a classification that treats complexity as an explicit input, reducing the configuration is the most direct way to make the argument smaller. Setting CONFIG_LOCALVERSION_AUTO so that uname -r carries the git revision joins the first two obligations at no cost.

These three are the part of a Linux safety certification that belongs to the team holding the BSP, but they are not the whole evidence pack. What a safety programme actually asks for looks more like this, and the useful discipline is to produce it as a release artefact rather than reconstruct it under assessment.

Category	Minimum useful artefact
Source identity	Remote, branch, immutable commit, and the ordered patch series above the stable base with who approved each
Build identity	Toolchain version, build-system revision, and for a Yocto build the layer revisions, locked source revisions and `buildhistory` output
Configuration	The shipped kernel configuration and the fragments that produced it, plus the kernel command line
Binary identity	Hashes of the kernel image, the device tree blobs, the modules and the release image
Hardware identity	SoC and board revision, memory and peripheral assignment, errata baseline
Interference analysis	Safety-related interfaces, shared resources, failure modes and the residual paths named earlier
Change control	The assessed baseline, each change since, and the impact analysis that accompanied it

On a Yocto-built platform this is worth emphasising: the kernel commit is not the whole provenance story. The layer revisions, the locked source revisions and the build configuration determine as much of what shipped as the kernel tree does, and a safety programme that records only the kernel commit will not be able to reproduce its own image. Assembling this is a different skill from writing kernel code, and it is the skill such programmes most often lack.

Key takeaways

A Linux safety certification bounds a configuration on named hardware, assessed by a named body, with assumptions transferred to the integrator. It is not a property of the kernel, and it does not give your item its ASIL.
ISO/PAS 8926:2024, published 29 January 2024, defines the route by which a pre-existing element enters an ISO 26262 argument, using classification rather than full qualification. Complexity is an explicit input, which makes configuration reduction the central activity.
ISO 26262-8:2018 moved to "to be revised" on 8 July 2024 and a draft successor is under development; no publication date is public, so do not plan around it.
Separate certified, certifiable and a safety package is available. Only the first names an assessor, though ISO 26262 requires an assessment rather than a certificate.
A Linux safety certification is a controlled baseline, not a frozen one: every patch, rebase and toolchain change needs an impact analysis against the certified scope.
ELISA states on its own site that it does not certify Linux.
Configuration identity, provenance and an exclusion argument are what the team holding the BSP will be asked to produce.

Frequently asked questions

Is the Linux kernel certified to ISO 26262?
No. A Linux safety certification attaches to a defined product configuration on named hardware, assessed by a named body against a named edition and integrity level. Red Hat's In-Vehicle Operating System, for example, is certified by exida against ISO 26262 Edition 2 (2018) as a Safety Element out of Context at ASIL-B.

Why does kernel configuration matter so much to a safety argument?
Because the examination of a pre-existing element requires showing that unused functionality cannot interfere or has been excluded, and ISO/PAS 8926:2024 names build-process configuration settings as the way that is done. Without an exact record of the shipped configuration the argument cannot be made.

Does a supplier certificate give my item its ASIL?
No. A Safety Element out of Context is assessed against an assumed integrity level, while the level your item needs comes from your own hazard analysis. The certificate establishes capability on condition that the Assumptions of Use hold in your design.

Does a matching kernel configuration prove the delivered image is the one you built?
No. It shows the Kconfig selections match. It says nothing about the patch stack, the compiler, the device tree, the modules or the final binaries, so pair it with the source commit identity and hashes of what was delivered.

Does ELISA membership mean a platform is safety certified?
No. ELISA's own workshop write-up published on 27 August 2026 records that it does not certify Linux and does not guarantee the safety of a complete product. It produces shared analysis, processes and tooling instead.

Epistemic Debt: The Code You Own but Cannot Explain

Raghu Bharadwaj — Thu, 03 Sep 2026 04:41:13 +0000

There is a kind of debt that never appears in the codebase. It is the distance between the code you own and the code you understand, and it stays completely invisible while everything is working. It reports itself for the first time on the day something has to be fixed, which is the worst possible day to discover how much of it you are carrying.

You are forward-porting a vendor kernel. It is two long-term releases behind, it carries somewhere over a thousand out-of-tree patches, and it has been shipping in a product for three years without trouble. A CVE is reported in a subsystem those patches touch, so the fix has to go in.

The port stops at patch 847. Not because anything is broken — nothing is broken. It stops because the patch conflicts, and the reason it exists is not written anywhere, and the engineer who wrote it left in 2021.

Everything needed to answer the question is present. The source is there, the history is there, the tree is one clone away. What is missing was never in the tree in the first place.

Technical debt is a decision somebody made. This is a decision nobody noticed making.

What the idea actually says

The name that has started to attach to this is epistemic debt: working software you own legally but do not own cognitively. Technical debt sits in the codebase. This sits in the engineer.

The two behave differently, and the whole difference is in how they get discovered. Technical debt is discoverable by reading. The awkward function is right there, the TODO is there, the eleven-minute build is there, and someone who has never seen the project can find all of it in an afternoon. It is visible continuously, which is exactly why teams manage it.

The other kind becomes visible under one condition only: something has broken, and the usual source of answers cannot help. Until that condition arrives, a system carrying an enormous amount of it looks identical to one carrying none. Same tests, same coverage number, same green build, same approvals.

You can see the difference in a single line of code. Take a spin_lock_irqsave() and write down why it is there. One version: it takes the lock and saves the interrupt flags. The other: local interrupts are disabled because this lock is also taken by the interrupt handler on this CPU, and without that the handler can try to take a lock this CPU already holds and deadlock us against ourselves; the _irqsave form exists because the caller may already have interrupts off, so the previous state has to be restored rather than interrupts unconditionally enabled.

The first sentence can be written by anyone who can read the line. The second cannot be written by anyone who does not hold a model of the locking context. Both are true. Only one of them is any use when the system is failing and you are the person on call.

There is no file to grep, no ticket, no build warning. There is only the day something breaks, and then you find out what you knew.

Why this matters more now, not less

Anything that produces working output faster than it produces understanding creates this debt. It is not new. Pasting an init sequence off a forum in 2009 created it. Inheriting a driver from someone who has left creates it. What has changed is the rate: a tool that writes a plausible page of code in four seconds moves the ratio between what you own and what you understand faster than any method before it, and it does so while every visible indicator improves.

That last part is the difficulty. The build is green. The review passed. The feature works. Every instrument you have says the work went well, and none of them is measuring the thing that is being used up.

One study has made the gap visible, and it is worth knowing about mainly for its design. Seventy-eight people built the same application in three groups — one unaided, one with an assistant, one with an assistant that would not let them merge anything until they had written down why the code worked. On the finished application the two assisted groups were indistinguishable. Then the assistant was taken away and a defect was injected into each person's own code, with thirty minutes to fix it. The group that had used the assistant freely repaired it at less than half the rate of the group that had been made to explain, and at a third of the rate of the group that never had one. It is a small study on novices, and its author says so. But nothing about the software recorded which group anyone was in.

Two groups shipped the same application. One could repair it and one could not, and no artefact anywhere recorded the difference.

The variable is not the tool. It is where the explanation gets required. The kernel worked this out a long time ago and wrote it into the process: Documentation/process/submitting-patches.rst requires you to describe the problem and justify the approach, and a changelog that only describes the diff is rejected. Every maintainer has been enforcing an explanation gate for thirty years without calling it one.

Which tells you where your own debt is sitting, and it is not upstream. Upstream extracts the explanation at the time, from everybody, on every patch, whether a person wrote it or a model did. It accumulates in the internal tree, in the vendor BSP, in the driver that ships in the product and never goes near a mailing list, because nothing there asks.

How to pay for it as you go

Write the internal changelog as though it were going upstream. Not what changed — what was wrong, and why this approach and not the obvious one. If the sentence could have been written by someone reading the diff, you have written the useless version.
Gate the places where wrong code looks right. A plain spin_lock() on a lock a hardirq handler also takes runs for months on a uniprocessor test board and deadlocks on the customer's SMP part. A devm_ allocation with a manual kfree() in the error path survives every test that never unbinds the device. None of these fail at review by inspection.
Let the tools tell you what you did not understand. CONFIG_PROVE_LOCKING exists to report that your lock ordering was a belief rather than a fact. KASAN and KCSAN do the same for lifetime and concurrent access. They run on a schedule instead of depending on your discipline, which is their main advantage over everything else on this list.
Ask for the explanation before you ask for the code. It costs nothing and it changes what you are left with when the answer arrives.
Break something you shipped and fix it unaided. Once a quarter. It is the only measurement of this that exists, and you can run it on yourself in an afternoon.

It is why we ask people to explain a patch before we treat it as finished. If you want that kind of practice with someone checking the explanation, that is what our Linux kernel and device driver programmes are built around.

Go back to patch 847. The company owns that kernel completely — the source, the history, the legal right, the revenue. What it does not own is the reason, and no amount of ownership produces that after the fact. The cost was taken on years earlier, on an ordinary afternoon, by someone who got something working and moved on. That is not a failure of diligence.

It is simply what this debt looks like at the moment you take it on, which is that it looks like nothing.

Ask yourself which of the things you shipped this year you could still repair with the assistant switched off.

Notice what that question is not. It is not an argument for using the tool less. The group in that study who used it freely produced good software, and so will you. It is a question about who is able to repair what you own. Technical debt can be paid down by anyone on the team, which is why it survives people leaving. This kind cannot. It is owed by one person, and the only way to settle it is to do the work that would have earned the understanding in the first place.

— Raghu Bharadwaj

How to Choose an Edge AI SoC: NPU, GPU, DSP, CPU, Memory, Power and the Software Stack

Raghu Bharadwaj — Wed, 02 Sep 2026 05:29:41 +0000

Choosing an Edge AI SoC on the TOPS number printed on the front page is the most common and most expensive mistake in this work, because those numbers are quoted in units that are not comparable to each other. The decision is settled instead by three things: whether a driver for that accelerator exists in a kernel you can actually ship, what happens to the layers the accelerator refuses to run, and whether the memory system can feed it. This guide works through all seven axes with figures taken from vendor documentation and kernel source, and gives you a checklist to run before you commit.

An Edge AI SoC selection usually starts as a spreadsheet with a TOPS column, and that spreadsheet is where the project goes wrong. Two years later the same team is explaining why a part rated at four times the throughput of its competitor delivers half the frame rate, or why a product cannot take a security update because the accelerator driver only exists for a kernel that reached end of life.

None of that is bad luck. Every one of those outcomes is visible at Edge AI SoC selection time, in documents the vendors publish, if you know which questions have answers and which do not. This guide goes through the seven axes in the order that they actually decide the outcome, which is close to the reverse of the order they appear in a datasheet.

The TOPS number is not a unit

Start here, because it clears away most of the spreadsheet. Below are throughput figures as the vendors themselves publish them, with the qualifier each one attaches. Every row is quoted from the vendor's own current documentation.

Part	Published figure	What the vendor actually says
Rockchip RK3588	up to 6 TOPS	No data type is attached to the number anywhere in the datasheet or the product page. Separately it lists int4, int8, int16, fp16, bf16 and tf32 support.
NXP i.MX 8M Plus	2.3 TOPS	No data type attached. Two SKUs in the family carry no NPU at all.
NXP i.MX 95	8 eTOPS at 1 GHz	The unit is written "eTOPS", not TOPS, and NXP does not publish what it normalises to.
TI AM62A	2 TOPS (8b)	Explicitly 8-bit, and explicitly quoted at the automotive worst-case junction temperature of 125 °C.
TI TDA4VM	8 TOPS (8b)	Same qualifiers. The C7x DSP beside it is quoted separately, in GFLOPS and GOPS.
Renesas RZ/V2H	8 TOPS dense, 80 TOPS sparse	The 80 is a pruning figure and the dense silicon number is 8. Reaching it means pruning the model and retraining it to recover accuracy, so it costs a labelled dataset and a training cycle.
Hailo-8	26 TOPS	No precision qualifier on the product page.
Hailo-10H	40 TOPS INT4, 20 TOPS INT8	The headline 40 is INT4. At INT8 it is 20.
Qualcomm QCS6490	12 dense TOPS	Qualcomm carries an explicit dense-versus-sparse footnote.
NVIDIA AGX Orin 64GB	275 sparse INT8 TOPS	170 sparse from the GPU, 105 sparse from the two DLA engines. Dense figures are 85 and 52.5. The 32GB module of the same name is 200.

Put those side by side and the comparison collapses. Renesas's 80 and NVIDIA's 275 are sparse; TI's 8 is dense 8-bit at 125 °C; Hailo-10H's 40 is INT4; NXP's 8 is a unit called eTOPS that has no published definition. Rockchip's 6 has no data type at all. There is no arithmetic that turns these into one another.

The NVIDIA row carries the sharpest lesson, because it is the only vendor here that publishes the split. On AGX Orin 64GB, 105 of the headline 275 comes from the two deep learning accelerator engines rather than the GPU. That is thirty-eight per cent of the number on the box sitting behind a fixed-function engine with a restricted layer set. If your network does not map onto that engine, the number you compared against is not the number you get. And Orin Nano, the cheapest member of the family, has no such engine at all — the developer guide lists its DLA core count as zero — so its entire figure is GPU.

Start with the driver, not the silicon

The question that decides an Edge AI SoC selection is not how fast the accelerator is. It is what runs it, on which kernel, maintained by whom.

Linux has a subsystem for exactly this hardware. It is drivers/accel, added in v6.2, and it is not a separate subsystem so much as a branch of DRM: the core is drm_accel.c, devices appear under major number 261 as /dev/accel/accel*, and drivers set DRIVER_COMPUTE_ACCEL in their DRM feature flags. In the master tree today it contains exactly six drivers.

raghu@techveda.org:~$ ls drivers/accel/
Kconfig  Makefile  amdxdna  drm_accel.c  ethosu  habanalabs  ivpu  qaic  rocket

Read that list carefully, because it is the whole upstream story. amdxdna and ivpu are x86-only, for the NPUs inside AMD and Intel laptop processors. habanalabs and qaic both depend on PCI: they are add-in cards for data centre and edge servers, and qaic in particular is a trap, because it is Qualcomm and it is upstream but it drives the Cloud AI 100 card, not the Hexagon NPU inside any Qualcomm SoC you would put in a product.

That leaves two in-tree drivers for NPUs embedded in application-class SoCs: rocket, which supports the Rockchip RK3588 and nothing else, and ethosu, which supports the Arm Ethos-U65 and U85 IP. The device tree binding directory tells the same story from the other side — Documentation/devicetree/bindings/npu/ contains two files, one for Arm Ethos and one for rockchip,rk3588-rknn-core.

Everything else on the market reaches its NPU through an out-of-tree vendor module. That is not automatically disqualifying, and for several of these parts it is the only realistic choice, but it must be priced honestly rather than discovered later.

Three more drivers have been posted to the lists and are not merged: accel/qda for Qualcomm DSPs, which reached a second revision in August 2026 with open questions in its own cover letter about device tree binding and privilege separation; accel/neutron for the NXP Neutron NPU; and an accel/npac request for comments. Posted is not merged, and merged is not shipped in a kernel you can use.

It is also worth being precise about what an in-tree driver gives you, because it is less than people assume. The kernel documentation for rocket says it plainly: the driver powers the hardware on and off, allocates and maps buffers, and submits jobs, and everything else happens in userspace in a Mesa driver. The kernel has no idea what a convolution is. Every question about which operators are supported is a userspace question on every one of these platforms, in-tree or not. We went through what that means in practice for one part in The Mainline NPU Driver on RK3588, and What It Cannot Do Yet.

The kernel version outlives the product

This is the axis that turns a good Edge AI SoC choice into a bad one three years later, and it is arithmetic rather than judgement.

The current longterm kernels and their projected end-of-life dates, from kernel.org:

Series	Released	Projected EOL
6.18	November 2025	December 2028
6.12	November 2024	December 2028
6.6	October 2023	December 2027
6.1	December 2022	December 2027
5.15	October 2021	December 2026
5.10	December 2020	December 2026

Those dates were last revised in February 2026, and the revision is instructive: 6.6, 6.12 and 6.18 all gained a year or two because enough companies depend on them, while 5.10 and 5.15 kept the dates they already had. The series you most want extended are the ones least likely to be.

Now combine that with when the drivers landed. The accel subsystem did not exist before v6.2, so a BSP based on 5.10, 5.15 or 6.1 cannot contain an in-tree accelerator driver by construction. rocket first appears in v6.18. ethosu first appears in v7.0, which is not a longterm series at all. So of the six maintained longterm kernels, exactly one contains an in-tree NPU driver for an embedded SoC, and it contains only the Rockchip one.

Set that against what the vendors actually ship. Rockchip publishes BSP branches for 4.4, 4.19, 5.10, 6.1, 6.6 and 6.12, with 6.1 as the default. NVIDIA currently ships two Jetson branches side by side: Jetson Linux 39.2.1 on kernel 6.8 with Ubuntu 24.04, and Jetson Linux 36.5.2 on kernel 5.15 with Ubuntu 22.04, both released in August 2026 and both supporting the full Orin range. "The Jetson kernel is 5.15" and "the Jetson kernel is 6.8" are both true statements, which is why you have to name the branch.

The consequence is concrete. Two of the six longterm series lose upstream stable fixes in December 2026, which from now is a matter of months. If your BSP is pinned there and your accelerator driver is an out-of-tree module written against those headers, then your security update path, your kernel upgrade path and your silicon vendor's roadmap are one single dependency. Ask, at selection time and in writing, which kernel the vendor will support at the end of your product's life, not which one they ship today.

NPU, GPU, DSP and CPU are one question

These four are usually presented as four separate rows in the comparison. They are better understood as a single question: when the accelerator refuses a layer, where does that layer go, and what does it cost?

Every Edge AI SoC here has a restricted accelerator and a fallback path. NVIDIA documents the restrictions on its DLA in unusual detail, and the list is instructive because it is representative rather than unusual: no dynamic dimensions, so minimum, maximum and optimum profile values must be equal; convolution kernel dimensions in the range 1 to 32; deconvolution padding must be zero; activation functions limited to ReLU, Sigmoid, TanH, clipped ReLU and leaky ReLU; the unary operations limited to absolute value, sine, cosine and arctangent; static slicing only; and at most sixteen loadables resident per core.

What happens to a layer outside that set is the part that hurts. NVIDIA's own documentation states that with GPU fallback enabled, layers that cannot run on the DLA fall back to GPU execution silently, without an error. A pipeline you believe is DLA-accelerated can be running entirely on the GPU, competing with everything else you put there, and nothing in the logs says so.

The same pattern repeats one level up. TensorFlow Lite's delegate documentation is explicit that if you hand a floating-point model to a delegate that only supports 8-bit quantized operations, it rejects all of them and the model runs entirely on the CPU. Not partially — entirely. ONNX Runtime's execution provider mechanism has the same shape, and it is worth knowing how thin the edge support tier is: the Rockchip NPU provider is marked preview and community-maintained, as are the Arm Compute Library, Arm NN and Vitis-AI providers.

This is where the DSP earns its place in the comparison, and TI is the clearest illustration because it publishes the split. On AM62A the matrix multiply accelerator does 2 TOPS of dense 8-bit work, and beside it sits a C7x vector DSP quoted at 40 GFLOPS. The MMA does dense integer matrix multiply; the C7x runs what the MMA cannot and provides the floating-point path; anything neither can take falls back to the Cortex-A cores. Renesas has the same two-part structure on RZ/V2H, where the vendor's own driver documentation defines DRP-AI as a reconfigurable processor plus an AI-MAC block described as hardware for high-speed 8-bit matrix operations.

So the useful question is not "how many TOPS", it is "what fraction of my graph lands on the fast path, and how fast is the slow path". A part with a modest accelerator and a strong vector DSP can beat a part with an impressive accelerator and nothing behind it, on a real network with unusual layers. You cannot answer this from a datasheet. You answer it by compiling your actual model with the vendor toolchain and reading the operator assignment report, which every one of these toolchains produces.

One practical warning about quantization while you are there. NXP documents that the i.MX 8M Plus NPU is optimised for per-tensor quantization, and that per-channel quantized models require additional compute and may carry a small accuracy error. Modern post-training quantization in both TensorFlow and PyTorch defaults to per-channel. The default export path is the slow path, and nothing tells you.

Memory decides more than the accelerator does

Three separate memory questions matter when sizing an Edge AI SoC, and teams routinely check only the first.

Capacity. Model weights, activation buffers and the working set of everything else on the board come out of the same DRAM. The part of that footprint the kernel cannot reclaim is invisible until an allocation fails, which we covered separately in The Half of an AI Model the Kernel Cannot Reclaim.

Bandwidth. This is the one that decides sustained throughput, and disclosure varies enormously. NVIDIA publishes a figure per module: 204.8 GB/s for AGX Orin on a 256-bit LPDDR5 interface, 102.4 GB/s for Orin NX on 128-bit, and 51 GB/s for the 4GB Orin Nano on 64-bit. That is a four-fold spread inside one product family, and it tracks the SKU price far more closely than the TOPS figure does. Qualcomm, by contrast, publishes bus width and clock — 2 x 16 LPDDR5 at 3200 MHz for QCS6490, 6 x 16 for the IQ-9075 — and no GB/s figure at all, so any Qualcomm bandwidth number you see has been computed by whoever wrote it down. TI publishes LPDDR4 at up to 3733 MT/s for AM62A and 4266 MT/s for TDA4VM. Rockchip's datasheet lists LPDDR4, LPDDR4X and LPDDR5 support across four 16-bit channels without a speed grade in the chapter I could retrieve.

Movement. This is the one that gets missed, and on a camera pipeline it is decisive. The question is whether a buffer captured by the camera can be handed to the accelerator without a copy. On Linux that means dma-buf, and it is not a given. The mainline rocket driver does not implement dma-buf export and registers no import hook, so a V4L2 capture buffer cannot be handed to the NPU as a dma-buf at all — you copy it into a driver buffer first, at every frame, on top of whatever else that memory is doing.

Underneath that sit two kernel facts worth checking on any candidate. First, whether the accelerator is behind an IOMMU, because that decides whether it can work from scattered pages or needs physically contiguous memory. The contrast is visible in the two in-tree drivers: rocket depends on ROCKCHIP_IOMMU, requires an iommus property in its binding and uses the shmem GEM helpers, while ethosu has no IOMMU path at all, uses the DMA GEM helpers and pulls its scratch memory from an on-SoC SRAM pool. Second, if you need contiguous memory, you need CMA, and CMA can only be used in sleeping context, deliberately bypasses single-page allocations and works by migrating movable pages, so it fails under fragmentation rather than degrading.

One more trap in the same area, because it will bite during a BSP upgrade rather than at selection: the default CMA dma-buf heap only got a stable name in Linux 6.17. Before that it could appear as reserved, linux,cma or default-pool depending on the platform, and it is now default_cma_region. Userspace that hardcodes the old name breaks on a new kernel, and vice versa.

Power is the axis nobody documents

Ask what an Edge AI SoC consumes and you discover that most vendors do not answer.

Rockchip's RK3588 datasheet — the only revision I could retrieve is Rev 0.1 from July 2021, marked as an initial release for special reference — has no SoC power section at all, only absolute ratings, recommended operating conditions and package thermal resistance. NXP publishes estimated maximum currents per supply rail for the i.MX 8M Plus and states explicitly that these are a guideline for power supply selection and that actual consumption for typical use cases is lower. TI publishes no typical figure for AM62A or TDA4VM, only the relative claim of the lowest power envelope in the industry at a 125 °C junction. Renesas publishes an efficiency ratio for RZ/V2H, 10 TOPS per watt, whose numerator is the pruning-inflated 80 rather than the dense 8.

The exceptions are worth noting because they show what disclosure looks like. Qualcomm states 6 to 9 W typical for QCS6490 and 3.8 to 20 W for the IQ-9075 SoC. Hailo states 2.5 W typical for both Hailo-8 and Hailo-10H — the same figure for parts of very different throughput, one of which carries external LPDDR4, which is worth treating with some caution rather than repeating.

NVIDIA documents this axis better than anyone here, through nvpmodel, and the detail rewards reading. In the r39.2.1 developer guide, AGX Orin 64GB offers MAXN, 15 W, 30 W and 50 W modes with 30 W as the default; Orin NX 16GB offers MAXN, 10 W, 15 W and 25 W with 15 W as the default. Two things in that table catch people out. MAXN carries a power budget of "n/a" rather than a wattage, and NVIDIA states in as many words that it is not the maximum performance mode, because hardware throttling engages when module power exceeds the TDP budget. And on Orin NX 16GB the number of available DLA cores is mode-dependent: two in MAXN, 25 W and 40 W, but one in the 10 W and 15 W modes — including the default. Choosing a power mode is also choosing how much accelerator you have.

The practical position is that for most of these parts you will have to measure power yourself, on your workload, in your enclosure. Budget for that. It is a week of work, and it is cheaper than discovering the thermal design is wrong after tooling.

The discrete accelerator is a real option

Before settling on a more expensive Edge AI SoC, price the other path: keep a modest SoC and attach a dedicated accelerator over PCIe. Hailo is the clearest example, and it has an unusual architecture — Hailo-8 integrates all its memory on die and requires no external DRAM, which means model weights must fit on chip. Hailo does not publish that capacity, and the practical evidence for the constraint is that Hailo-10H added a DDR interface specifically to reach larger models.

Two things decide whether this path works for you, and neither is the TOPS figure.

The first is the slot. Hailo publishes PCIe Gen 3 with four lanes for the M.2 Key M module, but two lanes for the Key B+M and Key A+E variants, and one lane for the 8R mPCIe module. That is a four-fold spread across parts that all carry the same headline number, and it interacts with what your carrier board actually routes, which is frequently narrower than the connector suggests.

The second is the driver, and here the accounting must be honest. The Hailo PCIe driver is GPL-2.0 and actively maintained on GitHub, and the HailoRT runtime is open source. But it is not in mainline, and — this is a verified negative rather than a claim about quality — no driver series has ever been posted to the kernel lists at all: a subject search and a diff-filename search on lore both return nothing. So this is an out-of-tree module you build and maintain against every kernel you ship, with the usual consequence that a kernel update can break it until the vendor catches up. That consequence is not theoretical: the module taints the kernel on load, and the vendor's own community forums carry recurring threads from people whose accelerator stopped building after a routine kernel upgrade. Note also that the driver's master branch supports only the Hailo-10 and Hailo-15 families, while Hailo-8 needs a separate branch.

That is a real cost, but it is a bounded and well-understood one, and it buys you the freedom to change the accelerator without changing the SoC, the BSP or the rest of the product. For many designs that is the better trade.

An Edge AI SoC checklist to run before you commit

None of the above requires a purchase order. Most of it can be answered in a day, on an evaluation board or against a kernel tree, and the answers are far more reliable than any comparison table.

On your build host, against the kernel source you intend to ship, find out whether the accelerator has an in-tree driver at all and which compatible strings it binds to:

raghu@techveda.org:~$ ls drivers/accel/
raghu@techveda.org:~$ ls Documentation/devicetree/bindings/npu/
raghu@techveda.org:~$ grep -rn "compatible" drivers/accel/*/[a-z]*_drv.c

If the answer is that there is no in-tree driver, that is a legitimate outcome and not a reason to stop. It tells you the vendor module is now a line item in your maintenance plan.

On the evaluation board itself, establish what is actually present at runtime. These read the board, so they are target-side:

root@evk:~# uname -r
root@evk:~# ls /dev/accel/ /sys/class/accel/ 2>/dev/null
root@evk:~# ls /dev/dma_heap/
root@evk:~# ls /sys/class/iommu/
root@evk:~# grep -i cma /proc/meminfo

Those five lines answer more than a week of datasheet reading. The kernel version tells you where you sit against the end-of-life table above. An empty /dev/accel confirms the accelerator is reached through a vendor module rather than the upstream framework. The heap listing tells you what buffer types you can actually allocate and whether a CMA region exists at all. The IOMMU listing tells you whether you are going to be fighting for contiguous memory. And the CMA figures in /proc/meminfo tell you how much of it you have before you have written any code.

Then do the one test that cannot be substituted: compile your real model with the vendor toolchain and read the operator assignment report. Every toolchain here produces one, and every one of them requires this step to happen on an x86 host rather than on the target — TI states plainly that model compilation cannot be performed on the SoC, and Renesas, Hailo and Rockchip all have the same offline structure. Count the operators that land on the accelerator and the ones that do not. That ratio, on your network, is the specification. The TOPS figure is marketing.

Finally, ask the vendor three questions in writing: which kernel version will be supported at the end of our product's lifetime; is the runtime library source-available or a binary; and what is the licence and distribution channel for the compiler. On several of these platforms the compiler is the closed part of an otherwise open stack, which is manageable, but only if you know before you commit.

What this means in practice

If you take one thing from this, make it the ordering. An Edge AI SoC is chosen on its software stack first, then memory, then power, and only then the accelerator's headline figure — because the first three are what you cannot change later, and the fourth is the one that gets all the attention.

A useful way to sanity-check a shortlist is to ask what happens in the worst case rather than the best. What is the frame rate when the model does not fit the accelerator's operator set? What is the update path when the kernel this driver was written against goes end of life? What is the memory bandwidth per inference when the display and camera pipelines are also running? Those three answers separate real candidates from spreadsheet candidates, and none of them appears on a product page.

The teams that get this right tend to do the same unglamorous thing: they buy two evaluation boards early, compile their actual model on both, and read the operator reports before anyone writes a requirements document. It costs a fortnight. It routinely saves a redesign. And it is the same principle we applied to quantization in 4-Bit Weight Quantization: Why the Memory System Decides — the constraint that governs is almost never the one on the front of the datasheet.

Key takeaways

TOPS figures are published in incompatible units: sparse versus dense, INT4 versus INT8, NXP's undefined "eTOPS", TI's figure at a 125 °C junction, and Rockchip's with no data type at all. They cannot be placed in one column.
Mainline drivers/accel holds six drivers, and only two serve NPUs in an embedded Edge AI SoC — rocket for the RK3588 alone, and ethosu for Arm Ethos-U. Everything else needs an out-of-tree vendor module.
The accel subsystem did not exist before v6.2, rocket arrived in 6.18 and ethosu in 7.0, so of the six longterm kernels only 6.18 carries an in-tree embedded NPU driver. The 5.10 and 5.15 series reach end of life in December 2026.
Every accelerator here has a restricted operator set and a fallback path, and the fallback is frequently silent: NVIDIA documents that DLA layers fall back to the GPU without an error, and a TensorFlow Lite delegate that rejects your operators runs the whole model on the CPU.
Memory has three questions, not one — capacity, bandwidth and whether a buffer can move without a copy. Mainline rocket has no dma-buf export, so a camera pipeline copies every frame.
Most vendors publish no SoC power figure at all. Plan to measure it yourself, on your workload, in your enclosure.
Compile your real model with the vendor toolchain and read the operator assignment report before you commit. That ratio is the specification.

Frequently asked questions

Can I compare TOPS figures between vendors at all?

Only after normalising them, and often not even then. The published figures use sparse and dense counts, INT4 and INT8 precisions, one undefined vendor-specific unit, and in one case a temperature qualifier. Several vendors attach no data type to the number. Treat the figure as an upper bound under the vendor's most favourable assumptions, and compare measured throughput on your own model instead.

Which embedded NPUs actually have an upstream Linux driver?

In the current mainline tree, two families: the Rockchip RK3588 through the rocket driver, and Arm Ethos-U65 and U85 through the ethosu driver. The other four drivers in drivers/accel are x86 laptop NPUs or PCIe cards. Drivers for Qualcomm DSPs and the NXP Neutron NPU have been posted to the mailing lists but are not merged.

Is an out-of-tree vendor NPU driver a reason to reject a part?

No, but it is a cost to price rather than discover. It means you build and maintain a module against every kernel you ship, a kernel update can break it until the vendor responds, and your upgrade path is tied to the vendor's roadmap. For most Edge AI SoC options on the market today it is the only available choice.

Why does my accelerated model still run slowly?

Most often because part of the graph never reaches the accelerator. Restricted operator sets mean unsupported layers fall back to the GPU, the DSP or the CPU, and that fallback is usually silent. Compile the model with the vendor toolchain, read the operator assignment report, and check how many operators actually landed on the fast path.

Should I use a discrete accelerator instead of a more capable SoC?

It is often the better trade, because it lets you change the accelerator without changing the SoC or the BSP. Two things decide it: the PCIe lane count your carrier board actually routes, which varies from one to four lanes across modules carrying the same headline figure, and the fact that the driver will be out of tree and maintained by you.

DEV Community: Raghu Bharadwaj

Kernel & Embedded News: Android Binder Goes Rust-Only in Linux 7.4

In this edition

Android Binder drops its C implementation

What it means for Android and embedded teams

io_uring proposes exchanging thread identities

How to read this if you build on io_uring

Orphaned VMs: guests that outlive the host kernel

What it means for fleet and hypervisor designs

Amlogic announces the first Cortex-A320 SoCs

How to evaluate the first Cortex-A320 parts

Ubuntu 26.10 finishes the move to Rust coreutils

How to check your images and scripts

References

Boot Confirmation: Who Decides an Update Worked?

The context

The boot confirmation options

Option A — a bootloader boot counter

Option B — a userspace health check

Option C — both, over a hardware watchdog

The decision

Consequences

Key takeaways

Frequently asked questions

Further reading

Containers vs Packages: Delivering Apps on an Embedded Device

The context

Containers vs packages: the four options

Option 1: the application lives in the base image

Option 2: a runtime package manager on the target

Option 3: OCI containers

Option 4: a separate artifact, without a container runtime

The decision

Consequences

Key takeaways

Frequently asked questions

Further reading

Kernel & Embedded News: Silent Data-Loss Bug Fixed; CRA Reporting Live

In this edition

A silent data-loss bug, present since Linux 6.6, is fixed with one line

How to check your device

CRA reporting is no longer a future obligation

What it means for manufacturers

Seven stable kernels, more than 9,000 patches, one Monday

What it means for teams consuming LTS kernels

Yocto 6.1 freezes: OpenSSL 4, rpm 6, kernel 7.2

What it means for Yocto-based products

U-Boot: one release candidate left, and new project infrastructure

How to check your build

Kernel builds are set to get a third faster

How to use it

References

A Certified Hypervisor Does Not Cover the Linux Guest

What the public register actually records

The strongest case for putting the critical function on the microkernel

Where a certified hypervisor stops

Three ways a device reaches a guest, and what each costs the argument

Interference the partition does not remove

What changed between December 2019 and March 2026

What the Linux guest is actually for

Key takeaways

Frequently asked questions

Further reading

Secure Boot Key Custody: Who Holds the Signing Key?

The context

The options

Option 1: key files in the source tree

Option 2: key files on a restricted build server

Option 3: a PKCS#11 token or HSM the build calls

Option 4: a detached signing step after the build

The decision

The consequences of secure boot key custody

Key takeaways

Frequently asked questions

Further reading

Kernel & Embedded News: Arm64 Drops Big-Endian, Boots CPUs in Parallel

In this edition

Arm64 prepares to remove big-endian support

How to check your device

Parallel CPU onlining through PSCI