Kernel & Embedded Digest: strncpy Removed in Linux 7.2

strncpy removed in Linux 7.2, sched_ext reorganised, post-quantum signatures in IMA and EVM, and a new 12 TOPS RISC-V module.

Three of this edition’s four items have a common thread: the kernel community is tightening the standard it applies to its own code and security. Linux 7.2 finally removes a string-handling function that caused bugs for years, reorganises the sched_ext source tree after a direct objection from Linus Torvalds, and adds post-quantum signature support to the integrity subsystem. The fourth item, a new RISC-V system-on-module with a 12 TOPS NPU, shows the edge-AI hardware that these kernels increasingly run on.

In this edition

strncpy is gone from the kernel in 7.2. After about six years and 362 commits, the last users of the deprecated strncpy() were removed and the API was deleted (Phoronix).
sched_ext source tree reorganised after a Torvalds complaint. New extensible-scheduler files were moved into kernel/sched/ext/ instead of being prefixed and dropped into the shared scheduler directory (Phoronix).
IMA and EVM gain post-quantum ML-DSA signatures in 7.2. The integrity subsystem can now verify files, modules and certificates with ML-DSA, plus it can delete measurement-list records to help resource-constrained systems (Phoronix).
Zhihe A210: an octa-core RISC-V SoC with a 12 TOPS NPU on a SO-DIMM module. Documentation and a development kit appeared, with a Buildroot and Debian SDK (CNX Software).

strncpy is finally removed from the kernel in Linux 7.2

Linux 7.2 removes the strncpy() function from the kernel entirely. As Phoronix reports, the work took about six years and roughly 362 commits to convert every in-tree user, after which the API and the per-architecture implementations were deleted.

The reason is well known. strncpy does not guarantee NUL termination when the source is as long as the destination, and it zero-fills the rest of the destination. That combination is both a frequent source of bugs and a waste of cycles.

The kernel now expects you to choose a function that states its intent. The practical mapping is direct:

strscpy() for a NUL-terminated destination.
strscpy_pad() when you also need the remaining bytes zero-filled.
strtomem_pad() for a fixed-width field that is deliberately not NUL-terminated.
memcpy_and_pad() for a bounded copy with explicit padding, and plain memcpy() when the length is known.

For in-tree code this change is already done. The group that should pay attention is anyone maintaining out-of-tree drivers or a vendor BSP. If your module still calls strncpy, it will fail to build against a 7.2 or later kernel, and a mechanical replacement is not always safe.

The correct replacement depends on whether the destination must be NUL-terminated, so I recommend reviewing each call rather than running a blanket substitution.

The wider lesson for teams is to treat the deprecated-API warnings the kernel emits as work items, not noise. A function that takes six years to remove from the mainline tree will take far longer to remove from a private fork if it is ignored.

sched_ext source tree reorganised after a direct objection from Torvalds

The main set of sched_ext changes for Linux 7.2 added more work on sub-scheduler support. sched_ext is the framework that lets you write CPU schedulers as user-space BPF programs and load them at runtime, which is useful when the default scheduler does not match a specific latency or throughput profile.

As Phoronix describes, Torvalds did not object to the features. He objected to the file layout: several new ext_-prefixed C and header files were placed directly in kernel/sched/ instead of in a dedicated sub-directory. He merged the pull request “under protest” and asked for the files to be grouped properly. A follow-up pull request then moved the code into kernel/sched/ext/, and that restructuring has been merged.

This is a small change in mechanical terms, and there is no functional difference for anyone loading a BPF scheduler. I include it because it is a useful signal about how the subsystem is being managed.

sched_ext is still relatively young, and the maintainers are being held to ordinary kernel housekeeping standards rather than being given slack because the feature is new. For embedded and real-time teams evaluating sched_ext as a way to express a custom scheduling policy without forking the core scheduler, that discipline is reassuring.

If you are tracking sched_ext, the practical note is minor but real: out-of-tree tooling, build scripts or documentation that referenced the old kernel/sched/ext_*.c paths needs to point at kernel/sched/ext/ from 7.2 onward.

IMA and EVM gain post-quantum ML-DSA signatures in Linux 7.2

The integrity subsystem changes for Linux 7.2 add support for ML-DSA signatures in IMA and EVM, the kernel facilities that measure and verify the integrity of files, kernel modules and certificates. ML-DSA is a post-quantum signature scheme standardised to replace RSA and ECC for use cases that need to remain secure against future quantum attacks.

As Phoronix notes, the same merge also lets the kernel remove records from the IMA measurement list. That list grows in a straight line over time and is held in kernel memory, so on a long-running, memory-limited device it can become a real constraint. Linux 7.2 allows staged deletion of records, with or without a confirmation step.

There are two separate reasons embedded teams should care. The first is the measurement-list deletion, which is an immediate, practical relief for resource-constrained systems that keep IMA enabled for secure boot and runtime integrity. If you have ever seen kernel memory climb on a device that runs for months without rebooting, this is directly relevant.

The second is the move to post-quantum signatures, which is a longer-horizon item. I do not recommend rushing a migration to ML-DSA for a product shipping today, because key sizes, signature sizes and verification cost are larger than RSA or ECC, and that matters on small flash and slow boot paths.

The action I do recommend is to confirm that your secure-boot and signing design can accept a larger signature scheme later without a redesign, because regulators and customers in safety and security-sensitive sectors are beginning to ask for a post-quantum path. Treat 7.2 as the point where the kernel-side building block exists, and plan the rest deliberately.

Zhihe A210: a 12 TOPS RISC-V module with a Buildroot and Debian SDK

On the hardware side, CNX Software reports that documentation and a development kit have appeared for the Zhihe A210, an octa-core RISC-V SoC built from four C920 cores and four C908 cores, paired with a 3D GPU, a video unit, and a 12 TOPS INT8 NPU.

It is offered as a SO-DIMM module on a carrier board, supports up to 16 GB of LPDDR4X, and includes a hardware security block with secure boot. The vendor ships a Linux SDK with Buildroot and Debian images and a toolkit for converting and deploying AI models to the NPU. A development kit is listed at roughly 334 US dollars, with the expectation that it may fall closer to 200 dollars.

The headline number is the 12 TOPS NPU, but the part of the report that matters more for an engineering decision is the software and the unresolved details. The SDK uses Buildroot and Debian, which is the practical route to a working image without building a full Yocto layer from scratch, and that lowers the initial effort to evaluate the board.

Two caution points stand out. First, the architecture profile is contested. The vendor’s marketing states RVA23, but readers in the comments point out that the C920 and C908 cores generally implement RVA22, and the profile determines whether a standard distribution toolchain will produce binaries that run unmodified. For RISC-V specifically, the profile claim is not a detail to take on trust; confirm it before committing.

Second, GPU support on RISC-V SoCs has historically depended on out-of-tree, vendor-supplied drivers rather than mainline code, and the comment thread raises exactly this concern for the likely PowerVR-class GPU here. For an NPU-centric workload that does not need 3D acceleration, that may not block you. For anything that needs a graphics stack, verify the driver situation first.

My recommendation for teams interested in RISC-V edge AI is to use a board like this for NPU and toolchain evaluation now, while keeping production commitments tied to confirmed mainline kernel support and a confirmed architecture profile.