Linux 7.3: AF_ALG Restricted by Default, YOLOX on Etnaviv

The theme this week is boundaries moving. The kernel is narrowing what user space may touch (AF_ALG), widening what mainline abstracts (accelerator fabrics, NPU inference), and firming up what platforms must guarantee (RISC-V profile extensions). Each of those shifts lands on embedded teams as either a migration task or a planning signal.

In this edition

• AF_ALG is restricted by default in Linux 7.3. A new sysctl limits the user-space crypto interface to an allowlist, and new AES library APIs define the in-kernel replacement path. — audit before you rebase
• Intel proposes DRM Fabric. A vendor-neutral topology layer for scale-up accelerator interconnects, posted days after AMD’s UALink enablement series. — long-term watch
• YOLOX runs on the open Etnaviv NPU stack. New operations bring a stronger object-detection model to Vivante NPUs in the i.MX 8M Plus and Amlogic A311D. — evaluate now
• RISC-V lands eleven ISA extensions in 7.3. Indirect CSR access, counter delegation, and QoS tagging move the platform toward server-class expectations. — planning signal
• Seven stable/LTS kernels and a Buildroot release wave shipped in one day. 7.1.10 down to 5.10.266, plus Buildroot security point releases. — patch now

Linux 7.3 puts AF_ALG behind an allowlist

The crypto pull for Linux 7.3, sent by maintainer Herbert Xu and now merged, contains the change this audience should read first: a new af_alg_restrict sysctl that defaults to 1. With the default in force, AF_ALG — the socket interface that lets user-space programs drive the kernel’s internal crypto algorithms — only accepts the algorithms on a curated allowlist. Eric Biggers authored the series, which also admits the additional ciphers cryptsetup needs and makes cbc(paes) available to privileged callers only.

This is the follow-through on a deprecation that has been building for several cycles. Linux 7.2 formally deprecated AF_ALG after zero-copy support and hardware offload had already been dropped; the maintainers have described the interface as a large attack surface with little remaining justification. 7.3 converts that position from an advisory into a default.

If your product uses AF_ALG, a kernel rebase to 7.3 can break it silently: the interface now defaults to allowlist-only operation. The failure mode is not a build error but a runtime one — socket or algorithm setup fails on a device that worked on 7.2.

The same pull also prunes embedded crypto drivers. The crypto_rng interfaces of the Allwinner sun8i-ce/sun8i-ss and NXP CAAM PRNGs were removed, the Qualcomm RNG moved fully under drivers/char/hw_random, and the Qualcomm qce crypto engine was marked BROKEN even as it gained runtime PM and interconnect-scaling work. Products on i.MX, Allwinner, or Qualcomm silicon that read random numbers or run crypto through these paths should re-check their configs on 7.3.

The constructive half of the story landed in a separate pull from Eric Biggers: library APIs for the AES modes the kernel actually uses — ECB, CBC, CBC-CTS, CTR, XCTR, XTS, GCM and CCM — with full documentation, wired into the traditional crypto API so the self-tests cover them. The old AES-GCM library is gone. Proof-of-concept conversions across kernel subsystems removed roughly 1,900 lines, and the stated plan is to migrate architecture-optimized AES code into the library in later cycles. In-kernel users get a simpler, faster path; user-space users are being pointed back at user-space crypto libraries.

How to check your device

Search your user space for AF_ALG use before you plan a 7.3 rebase, and inspect the new sysctl once you are on a 7.3 kernel:

raghu@techveda.org:~$ grep -rl "AF_ALG" rootfs/usr/ 2>/dev/null
raghu@techveda.org:~$ sysctl -a 2>/dev/null | grep af_alg

Common indirect users include libkcapi and OpenSSL engines configured for kernel crypto. If you find a dependency, migrate it to a user-space implementation, or plan to manage the allowlist deliberately and treat that as product configuration, not a default you inherit. Kernel-module authors using skcipher or AEAD for AES should track the new library APIs — that is where the maintained, optimized path is heading.

Intel proposes DRM Fabric for accelerator interconnects

Intel engineer Konstantin Sinyuk posted a twelve-patch RFC introducing “drm/fabric”: vendor-neutral, protocol-agnostic topology infrastructure for scale-up accelerator interconnects. The model is a strict hierarchy — a fabric groups the endpoints of one interconnect instance, an endpoint is one accelerator attachment holding physical ports, a port reports lane capability and operational state, and a peer names the directly adjacent accelerator or switch port. The core records direct adjacency only; route computation, switch forwarding, and the data path stay with vendor drivers and fabric controllers. The uAPI is Generic Netlink rather than sysfs, with query and provisioning operations, a synthetic provider for testing, and KUnit plus netlink selftests in the series.

The timing matters. Days earlier, AMD’s Alex Deucher posted a 95-patch series of about 7,000 lines enabling UALink — the open standard for linking up to 1,024 accelerators in one domain — in the AMDGPU driver, including remote memory access without copies and a dedicated address space with remote TLB shootdowns. Two vendors converging on mainline infrastructure for accelerator fabrics in the same fortnight means the interconnect layer is becoming ordinary kernel plumbing rather than a per-vendor SDK concern.

For embedded engineers this is a direction signal rather than a task. The pattern — netlink-based topology objects with vendor providers underneath — is the same shape as devlink in networking, and it is the shape multi-accelerator edge boxes will inherit when today’s datacenter interconnects scale down.

What it means for platform teams

Nothing here is merged; an RFC can change shape completely. Track the discussion if you build systems with more than one accelerator, because the uAPI that emerges will be the stable interface your orchestration and monitoring tools consume. Teams evaluating UALink-class hardware should note that topology discovery, error surfacing, and provisioning are being standardized now — the review threads are where objections still count.

YOLOX object detection on the open Etnaviv NPU stack

Tomeu Vizoso, working in partnership with Ideas On Board, has brought YOLOX object detection up on the Etnaviv driver stack for Vivante VIP NPUs — the neural accelerators in the NXP i.MX 8M Plus and the Amlogic A311D. YOLOX, an Apache-2.0 model from Megvii, is a meaningful step up in capability from SSDLite MobileDet, the model the stack supported until now.

The interesting part is what had to be built. FullyConnected now runs directly on the NN convolution cores. Reshape, Split, and Concatenate are handled purely as metadata changes, costing no hardware cycles. ReLU is fused into the output stage, Absolute and Logistic run as lookup-table operations on the tensor-processing cores, Subtract is lowered to a convolution, and Transpose is either fused or executed as a TP operation. Feature maps in signed 8-bit integers were added as well, which for some models increases accuracy at identical computational cost.

Each of those is a general capability, not a YOLOX special case — the operation coverage of the open stack just widened for every model that needs those primitives. This continues the pattern we covered with the mainline Rockchip NPU driver: open NPU stacks are moving from proof-of-concept classification demos toward the detection workloads products actually ship.

How to evaluate it

If you ship i.MX 8M Plus or A311D hardware, put the open stack on your benchmark board alongside the vendor SDK and measure your own model, not the demo. Check three things: whether your model’s operations are now covered, what accuracy you get from signed INT8 feature maps, and what the end-to-end latency looks like against the blob-based path. A fully mainline inference stack removes an entire vendor-SDK dependency from your BSP lifecycle — that is worth a day of benchmarking to validate.

RISC-V in 7.3: eleven extensions and server-class plumbing

The RISC-V pull for 7.3, sent by maintainer Paul Walmsley and merged, adds initial definitions and discovery for eleven ISA extensions: Smcsrind and Sscsrind (indirect CSR access), Smcntrpmf (privilege-mode filtering for the cycle and instret counters), Ssccfg and Smcdeleg (counter delegation to supervisor mode), Zicclsm, Ziccamoa, Ziccif, Ziccrse and Za64rs (cache, atomicity, and reservation-set guarantees from the profile specifications), and Ssqosid — quality-of-service resource tagging, which also gains CPU context-switch support via the new srmcfg CSR handling.

Around the extensions, the pull carries platform work with a clear direction: restart and power-off through UEFI runtime services when available, ACPI table upgrade support for debugging (matching ARM64 and x86), a smaller CFI shadow-stack allocation (2GB down to 512MB of address space), TLB-flush improvements using ASIDs and the Svinval extension, and build-time extraction of vDSO offsets to cut boot overhead. XIP kernel leftovers were removed.

Read together, this is the plumbing a platform needs before serious server and industrial deployment: delegated performance counters, QoS partitioning, firmware-managed power control, and profile-level guarantees that software can rely on across vendors. The extension list looks obscure item by item; collectively it is RISC-V being fitted for the same expectations Arm servers met a decade ago.

What it means for SoC selection

When evaluating RISC-V silicon for products with multi-year lifetimes, ask vendors which of these extensions their cores implement — counter delegation and Ssqosid in particular separate application-class designs from microcontroller-class ones. For BSP teams, the profile guarantees (Zicclsm, Ziccamoa, Ziccif, Ziccrse, Za64rs) are exposed through the kernel’s hwprobe interface, so user space can detect them without vendor-specific code. Devices shipping mixed workloads should watch Ssqosid: cache and bandwidth partitioning is how you keep an inference thread from starving your control loop.

A seven-branch stable wave and a Buildroot release day

On 23 August the stable series updated across every maintained branch in one wave: 7.1.10 on stable, and 6.18.46, 6.12.105, 6.6.153, 6.1.184, 5.15.217 and 5.10.266 on longterm. The same day, Buildroot shipped its 2026.08-rc2 release candidate together with two security bugfix releases, 2026.05.2 and 2025.02.17, covering both maintained stable branches; 2026.08-rc1 had arrived on 18 August. On the Yocto side, the 6.0.1 (Wrynose) and 5.0.17 (Scarthgap) point releases carry matching userspace fixes, including BusyBox CVE patches.

None of these releases is significant on its own, which is exactly why the wave gets missed. A coordinated multi-branch wave usually means fixes the stable maintainers wanted everywhere at once, and a build-system security release the same day means the userspace side of your image has pending patches too. The intake work is the story.

What it means for BSP teams

Diff the changelog of the branch you ship — networking, filesystem, and driver fixes in these waves regularly resolve field issues that were never reported upstream by name. Teams on 5.10 and 5.15 should confirm the projected end-of-life dates for those branches on kernel.org and have a migration plan that does not assume indefinite updates. Buildroot users on 2026.05 or 2025.02 should take the security point releases now, and start validating 2026.08-rc2 in CI so the stable release requires no extra work when it arrives. Treat the wave as one intake task: pin the new versions, rebuild, run your regression suite once.

References

• New AF_ALG restrictions with Linux 7.3 (Phoronix)
• Intel engineers propose DRM Fabric for Linux (Phoronix)
• AMD posts UALink enablement series for the Linux kernel (Phoronix)
• Etnaviv NPU update 22: YOLOX support (Tomeu Vizoso)
• kernel.org release listing (stable/longterm versions)
• Buildroot news: 2026.08-rc2, 2026.05.2, 2025.02.17
• Yocto Project 6.0.1 (Wrynose) release notes

— Raghu Bharadwaj