Raghu Bharadwaj

Posted on Aug 20 Originally published at techveda.live

Kernel & Embedded News: 32-bit Arm Deprecations in 7.3; Rsync 3.5

#linux #kernel #embedded #arm

This edition is about lifecycle edges. Linux 7.3 marks a broad set of older 32-bit Arm platforms deprecated ahead of removal, while at the other end Arm is preparing the kernel for 128-bit page table entries. In between: rsync 3.5.0 fixes 33 security issues in one release, Pine64 has paused new Linux device production over DRAM and eMMC prices, and Mojo is now fully open source following Qualcomm's acquisition of Modular.

By lifecycle edges I mean the places where support, security, supply, or tooling assumptions are changing under a product. The 7.3 merge window supplies two of them — one closing down the kernel's oldest Arm platforms, one opening the door to its largest future ones. The other three are a security release you should act on, a supply-chain warning, and an edge AI ecosystem shift.

In this edition

Linux 7.3 deprecates older 32-bit Arm platforms — 22 of the remaining 28 legacy board files, Cortex-M and ARM1136r0 support, and OABI userspace are marked deprecated; hundreds of drivers become removable once they go. — audit affected products now
rsync 3.5.0 fixes 33 security issues — a focused audit of path handling and the daemon protocol produced 33 CVEs, a critical proxy-protocol bypass among them, plus a hardened path-resolution framework. — patch now
Arm prepares 128-bit page table entries — an RFC series enables FEAT_D128 and the VMSAv9-128 translation system for larger address spaces on future Armv9.3+ hardware. — long-term watch
Pine64 pauses Linux device production — DRAM and eMMC shortages and prices have stopped new Linux hardware plans until at least mid-2027; microcontroller products continue. — planning signal
Mojo goes open source under Qualcomm — following the Modular acquisition and the Mojo 1.0 release, the entire language is now available under Apache 2.0. — strategic watch

Linux 7.3 deprecates older 32-bit Arm platforms

The SoC pull for Linux 7.3, merged on 19 August, contains the clearest signal yet on the future of legacy 32-bit Arm support. Arnd Bergmann has marked deprecated: 22 of the remaining 28 legacy board files that predate device tree, covering old Intel and Marvell chips; support for Cortex-M3/M4/M7 and ARM1136r0 CPU cores together with the 25 machines built on them; and be8, be32, OABI, and iwMMXt userspace binaries, which modern toolchains struggle to keep supporting.

The six board files that survive — TI OMAP1 and Samsung S3C64xx — stay because they still have known users. Among the deprecated Cortex-M and ARM1136 machines, most are reference boards; the notable exceptions Bergmann names are the Nokia N800/N810 tablets and the Buglabs BUG platform.

Nothing is removed in 7.3 itself. Bergmann's pull text says the deprecated code is retained so remaining users "continue to have the 7.3-LTS for a while longer" — phrasing that assumes 7.3 becomes this year's LTS, though the formal designation has not been made; our kernel lifecycle tracker follows that decision. Removal patches are being tested and removal is expected in a later cycle, possibly as early as 7.4; once it lands, hundreds of drivers used only by these platforms become removable in turn.

The same pull adds the new generation: Apple M3 Pro/Max/Ultra, Samsung Exynos 1580, Qualcomm's unannounced Shikra SoC on Cortex-A78C, Altera Agilex72 with Cortex-A720 cores, and the Sophgo SG2000, an Arm/RISC-V hybrid whose RISC-V cores now join its already-supported Cortex-A53. Boards gaining mainline support include the Milk-V Duo 256M and Duo S, and the Lenovo ThinkEdge SE70 built on the Jetson Xavier NX module.

How to check your device

If you ship anything on a pre-device-tree Arm board file, an ARM1136-class core, or OABI userspace, treat this cycle as the formal notice. Deprecation in 7.3 is the warning; removal is expected as early as 7.4, and the products that get hurt are the ones nobody is counting as users today. Check whether your platform is on the list in the pull request, and if it is, either speak up on the arm-kernel list now — known users are exactly what kept OMAP1 and S3C64xx alive — or plan your final kernel pin deliberately. This connects to the 2038 deadline we covered earlier: a frozen 32-bit kernel pin and an unfixed time_t tend to arrive together.

rsync 3.5.0 fixes 33 security issues in one release

rsync 3.5.0, released on 13 August, is described by its own release notes as an extraordinary release. A focused audit of rsync's path handling and daemon protocol, a companion fuzzing pass over the daemon protocol, and external researcher reports produced fixes for 33 security issues, each shipping with a regression test that fails on the unfixed tree.

The standout is CVE-2026-53791, rated critical: rsync daemons configured with proxy protocol enabled would accept a PROXY header from the client itself, allowing host-based access controls to be bypassed. A group of high-severity issues are symlink races — a local user plants a symlink and a privileged rsync follows it, letting the attacker choose where files are read from or written to. There are also remotely triggerable heap out-of-bounds writes in filter processing, argument parsing, and hard-link handling.

The release also introduces secure_relative_open(), a hardened path-resolution framework that pins directory file descriptors and refuses symlink hops that escape the transfer tree. The CVE advisories carry precise introduced-in ranges, many narrower than "everything before 3.5.0", so you can check exposure per version.

rsync deserves more security attention in embedded work than it usually gets. It runs as root in deployment scripts, factory provisioning, backup jobs on gateways, and NAS firmware, and the daemon mode listens on networks that are rarely as private as assumed.

raghu@techveda.org:~$ rsync --version

How to respond

Inventory where rsync runs privileged or as a daemon in your fleet and CI, starting with any rsyncd.conf that sets proxy protocol. Update to 3.5.0 where you build it yourself, and check your distribution's backport status where you do not — the per-CVE introduced-in ranges tell you which of your deployed versions are actually exposed. On multi-user systems, the symlink-race class matters even without the daemon.

Arm prepares the kernel for 128-bit page table entries

At the opposite end of the lifecycle from the 32-bit deprecations, work is under way to let the kernel handle page table entries that are 128 bits wide. FEAT_D128 is an optional feature of Armv9.3 and later that enables VMSAv9-128, a new translation system whose doubled descriptor size provides room for larger physical and virtual address ranges and additional feature bits for both hardware and software use.

A 16-part RFC series from Arm's Anshuman Khandual restructures the generic memory-management code first and then the arm64 code, gating the result behind a new CONFIG_ARM64_D128 option. The split matters: the generic MM changes touch code that every architecture uses, which is why this work is being socialised early as an RFC rather than sent straight at a merge window.

The limitations are still substantial — KVM and the Kernel Address Sanitizer do not yet work with D128 enabled, among other gaps — and no D128 hardware is shipping. This is infrastructure being laid years ahead of silicon, the same pattern 52-bit virtual addressing followed on arm64.

What it means for Arm platform work

There is no action to take on products, but two things are worth watching. First, the generic MM restructuring will land before the feature does, and out-of-tree memory-management patches — common in vendor BSPs — will need rebasing over it. Second, if you maintain arm64 platform code, the page-table-walking assumptions in your debugging tooling (crash scripts, JTAG-side walkers) will eventually need a 128-bit descriptor mode. Treat it as a long-term watch item, not a task for the current backlog.

Pine64 pauses Linux device production over memory prices

Pine64 announced on 19 August, via its community channels, that it has no plans to produce new Linux devices for now because of the DRAM and eMMC shortage and the prices that follow from it. The company says it will revisit the decision based on component pricing after mid-2027. Existing PineNote and PineTab2 stock is expected to last roughly three months, while the microcontroller-based products — PineTime, PineVoice, Pinecil — continue unaffected.

It is easy to file this under hobbyist news. It should not be. Pine64 operates on thin margins with small production runs and little purchasing leverage, which makes it an early indicator: the same DRAM and eMMC price pressure now sits inside the bill of materials of every small-run embedded product, industrial or consumer. AI-driven memory demand is repricing the components that Linux-capable devices cannot do without, and the vendors with the least leverage feel it first.

The gap between the two product classes in Pine64's own lineup makes the point: devices needing hundreds of megabytes of DRAM and gigabytes of eMMC are paused, while devices running on microcontroller-class memory carry on. That boundary — Linux-class versus MCU-class memory — is exactly where the current pricing pain concentrates.

What it means for product planning

If a 2026–27 build is on your roadmap, get memory pricing and allocation commitments in writing now rather than at layout time, and have the BOM reviewed for memory-footprint flexibility: a rootfs that fits 4GB eMMC instead of 8GB, or a kernel and userspace trimmed to hold 512MB of DRAM headroom, is suddenly worth real money per unit. Where footprint cannot shrink, consider qualifying a second memory vendor early — allocation, not just price, is the risk.

Mojo goes open source under Qualcomm

Modular — the company founded by Chris Lattner of LLVM and Swift — has open-sourced the entire Mojo language under the Apache 2.0 licence, following Qualcomm's recent acquisition of the company and last week's Mojo 1.0 release. Previously only the standard library was open. A Windows port is in progress alongside the existing Linux and macOS support.

Mojo targets a problem most edge AI teams eventually hit: kernel code for accelerators is written in vendor-specific stacks that do not travel between a GPU, an NPU, and a CPU fallback path. Mojo positions itself as a single systems language for that layer, with Python interoperability in both directions, which matters because the models and glue above it live in Python.

The interesting part is who now owns it. Qualcomm ships edge silicon whose AI story has long depended on its proprietary Hexagon toolchain, and it has bought a compiler company and immediately opened its flagship language. One strategic reading — and it is a reading, not a stated plan — is that Qualcomm wants Mojo to become the portable kernel layer for edge accelerators, with openness as the necessary price, because nobody adopts a single-vendor language for cross-vendor code. The unanswered questions are governance and targets: whether non-Qualcomm accelerator backends appear, and who besides Qualcomm gets a seat in steering the language.

How to evaluate it

Treat Mojo as a candidate for new accelerator-kernel code where you would otherwise commit to a single vendor's stack, not as a reason to rewrite working CUDA or OpenCL. Concrete checks before betting on it: confirm the Apache 2.0 tree actually builds your target without proprietary components, look for a published governance model, and watch whether a non-Qualcomm backend lands. The first of those three to move tells you whether this is an open ecosystem or an open-core funnel.

References

— Raghu Bharadwaj

I teach Linux kernel and embedded systems engineering at TECH VEDA — hands-on training for engineers building products on Linux.

DEV Community