news
LWN on Kernel, Python, and Arch
Just kernel for now, more here.
-
LWN ☛ On the use of LLM assistants for kernel development [Ed: Slop or plagiarism should be turned down by all projects; those caught ought to be banned as they can never be trusted anymore.]
By some appearances, at least, the kernel community has been relatively insulated from the onslaught of AI-driven software-development tools. There has not been a flood of vibe-coded memory-management patches — yet. But kernel development is, in the end, software development, and these tools threaten to change many aspects of how software development is done. In a world where companies are actively pushing their developers to use these tools, it is not surprising that the topic is increasingly prominent in kernel circles as well. There are currently a number of ongoing discussions about how tools based on large language models (LLMs) fit into the kernel-development community.
Arguably, the current round of debate began with this article on a presentation by Sasha Levin at the Open Source Summit North America in June; his use of an LLM to generate a kernel patch came as a surprise to some developers, including the maintainer who accepted that patch. Since then, David Alan Gilbert has posted a patch proposing requirements for the disclosure of LLM use in kernel development. Levin has posted a series of his own focused on providing configurations for coding assistants and guidelines for their use. Both of these submissions have provoked discussions ranging beyond their relatively narrow objectives.
-
LWN ☛ The rest of the 6.17 merge window
The 6.17-rc1 prepatch was released by Linus Torvalds on August 10; the 6.17 merge window is now closed. There were 11,404 non-merge changesets pulled into the mainline this time around, a little over 7,000 of which came in after the first-half merge-window summary was written. As one would expect, quite a few changes and new features were included in that work.
-
LWN ☛ Possible paths for signing BPF programs
BPF programs are loaded directly into the kernel. Even though the verifier protects the kernel from certain kinds of misbehavior in BPF programs, some people are still justifiably concerned about adding unsigned code to their kernel. A fully correct BPF program can still be used to expose sensitive data, for example. To remedy this, Blaise Boscaccy and KP Singh have both shared patch sets that add ways to verify cryptographic signatures of BPF programs, allowing users to configure their kernels to load only pre-approved BPF programs. This work follows on from the discussion at the Linux Storage, Filesystem, Memory-Management, and BPF Summit (LSFMM+BPF) in April and Boscaccy's earlier proposal of a Linux Security Module (LSM) to accomplish the same goal. There are still some fundamental disagreements over the best approach to signing BPF programs, however.
The kernel can already check signatures on loadable kernel modules; what makes BPF programs more difficult? The main culprit is "compile once — run everywhere" (CO-RE) relocations. BPF programs need to access internal kernel data structures, but those data structures can be different between kernel versions, architectures, or configurations. In the same way that normal ELF relocations modify a program to account for the run-time memory layout of its libraries, CO-RE relocations modify a BPF program to account for differences between kernel versions.