Kernel: New in LWN (Outside the Paywall) and Rust Burden
-
LWN ☛ The BPF-programmable network device
Containers and virtual machines on Linux communicate with the world via virtual network devices. This arrangement makes the full power of the Linux networking stack available, but it imposes the full overhead of that stack as well. Often, the routing of this networking traffic can be handled with relatively simple logic; the BPF-programmable network device, which was merged for the 6.7 kernel release, makes it possible to avoid expensive network processing, in at least some cases.
When a guest (either a container or a virtual machine) sends data over the network in current systems, that data first enters the network stack within that guest, where it is formed into packets and sent out through the virtual interface. On the host side, that packet is received and handled, once again within the network stack. If the packet is destined for a peer outside of the host, the packet will be routed to a (real) network interface for retransmission. The guest's data has made it into the world, but only after having passed through two network stacks.
-
LWN ☛ The first half of the 6.7 merge window
As of this writing, 9,842 non-merge changesets have found their way into the mainline repository since the 6.7 merge window opened. Nearly a third of those consist of the entire bcachefs development history but, even discounting that, there has been a lot of material landing for the next release. Read on for a summary of the most interesting changes pulled so far in this development cycle.
-
LWN ☛ Guest-first memory for KVM
One of the core objectives of any confidential-computing implementation is to protect a guest system's memory from access by actors outside of the guest itself. The host computer and hypervisor are part of the group that is to be excluded from such access; indeed, they are often seen as threat in their own right. Hardware vendors have added features like memory encryption to make memory inaccessible to the host, but such features can be difficult to use and are not available on all CPUs, so there is ongoing interest in software-only solutions that can improve confidentiality. The guest-first memory patch set, posted by Sean Christopherson and containing work by several developers, looks poised to bring some software-based protection to an upcoming kernel release.
Protecting memory from the host in the absence of encryption tends to rely on address-space isolation — arranging things so that the host has no path by which to access a guest's memory. The protection in this case is less complete — an overtly hostile host kernel can undo it — but it can be effective against many host-side exploits. Back in 2020, the KVM protected memory work created a new hypercall with which a guest could request that the host unmap a range of memory in use by that guest; that would render the host system (at both the kernel and user-space levels) unable to access that memory. That work ran into a number of problems, though, and never found its way into the mainline.
-
LWN ☛ Reducing patch postings to linux-kernel
The linux-kernel mailing list famously gets an enormous amount of email on a daily basis; the volume is so high that various email providers try to rate-limit it, which can lead to huge backlogs on the sending side and, of course, delayed mail. Part of the reason there is so much traffic is that nearly every patch gets copied to the mailing list, even when it may be unnecessary to do so. A proposed change would start shunting some of that patch email aside and, as might be guessed, has both supporters and detractors, but the discussion does highlight some of the different ways the mailing list is used by kernel developers.
-
ZDNet ☛ Rust in Linux: Where we are and where we're going next [Ed: There are downsides [1, 2], but this is an LF-funded site pushing the interests of GAFAM. LF needs to ask Microsoft for permissions before saying things and it's not different for Microsoft-bribed "news" sites, which are casually censored by the company.]
Step by step, the Rust programming language is moving deeper into the GNU/Linux kernel.
[...]
At the Linux Plumbers Conference in Richmond, Virginia, Linux and Rust developer Miguel Ojeda gave the Linux kernel developers an update on the state of Rust in the Linux kernel. In brief, Rust Linux is continuing to mature and is getting strong support from developers and vendors, such as Cisco, Samsung, and Canonical.
Of course, Rust has been in Linux since Linus Torvalds gave the memory-safe language his blessing for the Linux 6.1 release. Now, though, Rust is taking the steps it needs to become -- along with C -- a fully-fledged member of the Linux language toolchain.