LWN Coverage of Kernel
-
LWN ☛ Arithmetic overflow mitigation in the kernel
On May 7, Kees Cook sent a proposal to the linux-kernel mailing list, asking for the kernel developers to start working on a way to mitigate unintentional arithmetic overflow, which has been a source of many bugs. This is not the first time Cook has made a request along these lines; he sent a related patch set in January 2024. Several core developers objected to the plan for different reasons. After receiving their feedback, Cook modified his approach to tackle the problem in a series of smaller steps.
Cook referenced his slides from a talk at the 2024 Linux Security Summit North America, saying that the kernel has ""averaged about 6 major integer overflow flaws a year"". In his email, he was clear that he was not talking about undefined behavior: ""We already demand from our compilers that all our arithmetic uses a well-defined overflow resolution strategy; overflow results in wrap-around (thanks to '-fno-strict-overflow').""
-
LWN ☛ Direct-to-device networking
It has been nearly one year since the first version of the device memory TCP patches was posted by Mina Almasry. Now on the 14th revision, this series appears to be stabilizing. Device memory TCP is a specialized networking feature requiring a certain amount of setup, but it could provide a significant performance improvement for some data-intensive applications.
The kernel's networking stack is designed to manage data transfer between the system's memory and a network device. Much of the time, data will be copied into a kernel buffer on its way to or from user space; in some cases, there are zero-copy options that can accelerate the process. But even zero-copy operations can be wasteful when the ultimate source or sink for the data is a peripheral device. An application that is, for example, reading data from a remote system and feeding it into a device like a machine-learning accelerator may never actually look at the data it is moving.
-
LWN ☛ Eliminating indirect calls for security modules
Like many kernel subsystems, the Linux security module (LSM) subsystem makes extensive use of indirect function calls. Those calls, however, are increasingly problematic, and the pressure to remove them has been growing. The good news is that there is a patch series from KP Singh that accomplishes that goal. Its progress into the mainline has been slow — this change was first proposed by Brendan Jackman and Paul Renauld in 2020 — and this work has been caught up in some wider controversies along the way, but it should be close to being ready.
A security module provides a set of hooks, one for each operation within the kernel that it wants to control. Whenever that operation (opening a file, for example, or creating a new process) is invoked by user space, the security module's hook function will be called with information about the requested action. The hook then has the opportunity to see whether an action is allowed by the policy it is meant to enforce and, if not, block that action. The kernel can have more than one security module active at a time, each of which provides its own hook functions. Those functions are stored in a linked list; traversing that list and calling all of the hook functions is where the indirect calls come in.
-
LWN ☛ Mount notifications
There are a handful of extensions to the "new" mount API that Christian Brauner wanted to discuss as part of a filesystem session at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit. In the session, though, the only one that he got to was a followup to last year's discussion on mount-operation monitoring. There is a need for user-space programs to be able to follow mount operations (e.g. mount and unmount) that happen in the system, especially for tools like container managers or systemd.
He began by briefly listing the potential topics in his slides, but noted that he was doubtful that he would get far into the list—or even past the first. He chose to focus on mount-operation monitoring (or mount notifications) as it is "the most pressing and interesting issue for user space". The idea is that user-space tools can register for mount-related events, which will allow them to track the state of the mount tree.