Kernel & Embedded News: ARM Removals 2027; BPF Hardened

The Linux kernel community spent this week managing its own long-term health: a restarted plan to remove old ARM platforms in early 2027, BPF JIT hardening merged ahead of 7.2-rc2, and a proposal to drop the Assisted-by tag for AI-assisted patches. On the hardware side, EDATEC launched a Raspberry Pi CM0 industrial data acquisition gateway with isolated DI/DO for about $150.

Old ARM platforms scheduled for removal in early 2027, BPF JIT-spraying hardening in 7.2-rc2, the Assisted-by attribution debate, and a Raspberry Pi CM0 industrial gateway.

Three of the four items this week concern how the kernel community maintains itself: which platform code stays in the tree, how a long-standing JIT side channel gets closed, and how AI tool usage should be recorded in commit history. The fourth item shows the Raspberry Pi compute ecosystem moving further into industrial I/O territory that PLC-adjacent hardware used to own.

In this edition

Old ARM platforms head for removal in early 2027. Arnd Bergmann has restarted the deprecation plan for non-devicetree board files, ARMv6/ARM1136r0 with OMAP24xx and i.MX31, Cortex-M microcontroller support, and more (Phoronix).
BPF JIT memory reuse hardened against JIT spraying. Post-merge-window patches for Linux 7.2-rc2 flush indirect branch predictors when BPF JIT memory is reused (Phoronix).
Kernel developers debate dropping AI attribution tags. Christian Brauner questioned the Assisted-by requirement, and Jeff Layton has posted a patch to remove it entirely (Phoronix).
EDATEC ED-IPC1200: a Raspberry Pi CM0 data acquisition gateway. RS-485, RS-232, and isolated digital I/O in a DIN-rail box, with samples at roughly $150–200 (CNX Software).

Old ARM platforms scheduled for removal in early 2027

ARM Linux maintainer Arnd Bergmann restarted a long-pending discussion on 1 July: deprecating and then removing a set of outdated ARM platforms and features from the kernel in early 2027, after this year’s LTS release (Phoronix). The original proposal dates to July 2024 and had broad maintainer agreement, but the removals never happened. Given current release timing, the changes would likely land in Linux 7.4.

The list includes: all board files still not converted to devicetree (with OMAP1 and S3C excepted), iWMMXt FPU support, ARMv6/ARM1136r0 support along with the OMAP24xx and i.MX31 SoCs that use it, Cortex-M3/M4/M7 microcontroller support (stm32, imxrt, lpc18xx, samv7), the LSI Axxia platform, and OABI support, which is now confined to StrongARM builds and goes when StrongARM goes. Big-endian ARMv7 is being marked BROKEN rather than removed, which lowers its testing requirements. Details are in the LKML thread.

For most teams this changes nothing, because these platforms stopped appearing in new designs years ago. The exposure is in long-lived industrial products: an i.MX31 or OMAP24xx device still receiving software updates, or a legacy board supported through a non-devicetree board file, loses its path to newer kernels once the removal lands.

Teams in that position have a clear decision window. Pin the product to the 2026 LTS kernel and plan a hardware refresh against that support horizon, or invest now in converting the board support to devicetree so it survives upstream. The devicetree conversion is real work, but it is far cheaper while the surrounding platform code still exists in the tree to reference. This kind of board-file-to-devicetree migration is also a well-defined skill;

The Cortex-M removal deserves a separate note: it covers running Linux itself (no-MMU) on M3/M4/M7 parts, not general microcontroller work. Almost everyone on those parts today runs Zephyr, FreeRTOS, or bare metal, so the practical impact is small — but if you have a uClinux-style deployment on STM32 or i.MXRT, treat this as the formal end of upstream support.

BPF JIT memory reuse hardened against JIT spraying

Patches merged ahead of Linux 7.2-rc2 harden the kernel’s BPF JIT against JIT spraying attacks (Phoronix). The BPF JIT allocator packs many small programs into larger executable allocations and reuses space as programs load and unload. The problem: when fresh code is written where an old program lived, an indirect jump into the new program can reuse a branch prediction left behind by the old one.

Intel engineer Pawan Gupta’s first patch introduces a bpf_arch_pred_flush static call that flushes indirect branch predictors before JIT memory is reused; by default it is a no-op, and architectures that need a flush wire in their own function. A second patch enables an IBPB flush on x86 when Spectre-v2 mitigations are in use, skipping it if the BPF dispatcher already uses a retpoline sequence. Classic BPF programs — the unprivileged attack surface — are bounded well below the pack size, which keeps the flush coverage sound.

The unprivileged angle is the part worth acting on. Confirm that kernel.unprivileged_bpf_disabled is set on your products; most distributions have defaulted to disabling unprivileged BPF for years, but embedded images built from scratch do not always carry that setting. With unprivileged BPF disabled, this attack surface is limited to processes that already hold CAP_BPF.

The performance cost is an IBPB on JIT memory reuse, which only matters for workloads that load and unload BPF programs at high frequency. Typical observability and tracing deployments load programs once and keep them resident, so the overhead there is negligible. Expect this to reach stable kernels through normal backports given its security nature, though no explicit backport commitment has been stated yet.

The Assisted-by debate: how should the kernel record AI tool usage?

Kernel documentation has for some months asked that patches created with AI/LLM assistance carry an Assisted-by tag naming the tool, model version, and other details. Christian Brauner opened an LKML thread on 1 July arguing the git history “has effectively started to function a bit like a free advertising platform” for AI companies, and suggested either simplifying the tag to a bare tool name or removing the requirement (Phoronix).

A day later, Jeff Layton posted a patch proposing to drop the requirement entirely. His reasoning is direct: the tag is not universally followed, it advertises proprietary LLM vendors, and it is unclear what the collected data is for. Linus Torvalds has not commented on either thread yet.

The underlying position both threads converge on is worth understanding: accountability in the kernel flows through Signed-off-by, and the human who signs off owns the patch regardless of which tools produced it. An Assisted-by tag neither adds to nor subtracts from that responsibility, which is why its information value is being questioned.

For engineers preparing their first upstream contributions, the practical reading is simple. Watch the outcome before templating commit messages around the current documentation, and put your effort into the part that policy cannot change: you must be able to explain and defend every line you submit, however it was written. For engineering managers, the same applies internally — if your organisation wants to track AI usage in its own trees, build that into your own process rather than relying on upstream tag conventions that are now in flux.

EDATEC ED-IPC1200: Raspberry Pi CM0 moves into data acquisition

EDATEC has launched the ED-IPC1200, an industrial data acquisition gateway built on the Raspberry Pi Compute Module Zero (CNX Software). The CM0 carries the Broadcom BCM2710A1 — four Cortex-A53 cores at 1.0 GHz — with 512 MB RAM and 8 or 16 GB eMMC. Around it the box adds two RS-485 ports, one RS-232, four digital inputs and four digital outputs with 3.75 kV isolation, 10/100 Ethernet, optional Wi-Fi and 4G LTE (regional Quectel EC800 variants), a supercapacitor-backed RTC, 9–28 V DC input at about 5 W, DIN-rail mounting, and a -20°C to +60°C operating range. Samples are on DigiKey at roughly $150–200.

The isolated DI/DO is what distinguishes this from the earlier ED-IPC1100, which was a connectivity box; this one can drive relays and read field sensors directly. An ED-IPC1220 with 8x DI, 8x DO, and analog current/voltage inputs is already listed and due shortly. EDATEC supports Raspberry Pi OS with drivers for the industrial interfaces, plus CODESYS, Node-RED, Python, and OpenCV.

The value here is the software position, not the silicon. A Modbus RTU/TCP gateway, a protocol converter, or a lightweight SCADA edge node on this hardware inherits Raspberry Pi OS’s long support life and an enormous knowledge base, which is exactly what small industrial deployments struggle to get from no-name gateway vendors.

Be realistic about the ceiling. 512 MB of RAM rules out heavy container stacks, the Ethernet port is 10/100, and the CM0’s single-lane USB 2.0 world is not built for high-rate acquisition. Size the workload before committing: measure memory headroom with your actual protocol stack and logging pipeline running, and if the numbers are tight, the CM4/CM5-based alternatives cost more but remove the constraint. For plain serial-to-network data acquisition with a few isolated control points, this class of device at this price is difficult to argue against.