The Linux kernel uses a number of hardening techniques to try to protect itself against compromise; one of those is kernel address-space layout randomization (KASLR). But randomization is of little benefit if the kernel spills the beans on where its code has ended up. As it happens, the kernel has been doing exactly that — since 2007, in a behavior that predates the addition of KASLR. Some changes are in the works to close that hole, but it is illustrative of just how hard some secrets are to keep.

Version 2.44.0 of the Git source-code management system has been released. There is a long list of changes, including the git replay command for faster, server-side rebasing, a number of command-line completion improvements, and more.

Linus has released 6.8-rc6 for testing.

Last week I said that I was hoping things would calm down a bit. Technically things did calm down a bit, and rc6 is smaller than rc5 was. But not by a huge amount, and honestly, while there's nothing really alarming here, there's more here than I would really like at this point in the release.

So this may end up being one of those releases that get an rc8. We'll see.

In a recent episode, "Pitchforks for RDSEED", we learned that there was some uncertainty around whether hardware-based random-number generators on x86 CPUs could fail. Since the consequences of failure in some situations (confidential-computing applications in particular) can be catastrophic, there was some concern about this prospect and what to do about it. Since then, the situation has come a bit more into focus, and there would appear to be an agreed-upon plan for changes to be made to the kernel.

Security updates have been issued by Debian (engrampa and libgit2), Fedora (libxls, perl-Spreadsheet-ParseXLSX, and wpa_supplicant), Gentoo (PyYAML), Mageia (packages and thunderbird), Red Hat (firefox, kernel, linux-firmware, thunderbird, and unbound), Slackware (openjpeg), SUSE (golang-github-prometheus-prometheus, installation-images, kernel, python-azure-core, python-azure-storage-blob, salt and python-pyzmq, SUSE Manager 4.2.11, SUSE Manager 4.3, SUSE Manager Server 4.2, and wayland), and Ubuntu (dnsmasq, libde265, libxml2, openjdk-17, openjdk-21, openjdk-lts, and postgresql-12, postgresql-14, postgresql-15).

Netflix has announced the release of a tool called bpftop to help with the performance optimization of BPF programs in the kernel:

bpftop provides a dynamic real-time view of running eBPF programs. It displays the average execution runtime, events per second, and estimated total CPU % for each program. This tool minimizes overhead by enabling performance statistics only while it is active.

The Open Collective Foundation is an organization created to provide legal and financial services for non-profit projects, many of which are associated with free software. Projects hosted there are now beginning to report that the Open Collective Foundation will be shutting down at the end of the year, with an unwinding process over that time.

Unfortunately, over the past year, we have learned that Open Collective Foundation's business model is not sustainable with the number of complex services we have offered and the fees we pay to the Open Collective Inc. tech platform.

In late 2023, we made the decision to pause accepting new collectives in order to create space for us to address the issues. Unfortunately, it became clear that it would not be financially feasible to make the necessary corrections, and we determined that OCF is not viable.

Some more information can be found in the Dissolution FAQ. Note that the Open Collective Foundation is distinct from Open Source Collective, which has hastened to point out that it remains in operation as before, and both are distinct from the Open Collective platform.

The LWN.net Weekly Edition for February 29, 2024 is available.

The Linux kernel follows a monolithic design, and that brings a well-known problem: all code in the kernel has access to the entirety of the kernel's address space. As a result, a bug in (for example) an obscure driver may well be exploitable to wreak havoc on core-kernel data structures. Various attempts have been made over the years to increase the degree of isolation within the kernel. The latest of these, "SandBox Mode" proposed by Petr Tesařík, makes it possible for the kernel to run some limited code safely, but it has encountered a bit of a chilly reception.

The 6.7.8 and 6.6.20 stable kernel updates have been released. They contain a single patch addressing an ntfs3 filesystem build error introduced in the previous round of updates.

The 6.8-rc7 kernel prepatch is out for testing.

So we finally have a week where things have calmed down, and in fact 6.8-rc7 is smaller than usual at this point in time. So if that keeps up (but that's a fairly notable "if") I won't feel like I need to do an rc8 this release after all.

So no guarantees, but assuming no bad surprises, we'll have the final 6.8 next weekend.

Security updates have been issued by Debian (yard), Oracle (buildah and kernel), Red Hat (389-ds:1.4, edk2, frr, gnutls, haproxy, libfastjson, libX11, postgresql:12, sqlite, squid, squid:4, tcpdump, and tomcat), SUSE (apache2-mod_auth_openidc and glibc), and Ubuntu (linux-gke, python-cryptography, and python-django).

The kernel's memory-management subsystem is built on the concept of "zones", which were initially added to describe the physical characteristics of the memory pages contained within them. Over time, zones have taken on more of a policy-related role as well. With a patch set called THP allocator optimizations, Yu Zhao has set out to better define the role of policy-related zones on the path toward adding two more of them, with the ultimate purpose of improving the kernel's support for transparent huge pages (THPs).

The LWN.net Weekly Edition for March 7, 2024 is available.

Before loading a BPF program, the kernel must verify that the program is safe to run; among other things, that verification includes ensuring that the program will terminate within a bounded time. That requirement has long made writing loops in BPF a challenging task. The situation has improved over the years for some types of loops, but others — including linked-list traversal — are still awkward in BPF programs. A new set of BPF primitives aims to make life easier for this use case through the installation of what can be seen as a sort of circuit breaker.

Andrew 'bunnie' Huang provides an update on his IRIS infrared chip-scanning project as the starting point for a detailed summary on how chip customers can detect forgeries and modifications in general.

The technique works because although silicon looks opaque at visible light, it is transparent starting at near-infrared wavelengths (roughly 1000 nm and longer). Today's commodity optics and CMOS cameras are actually capable of working with lights at this wavelength; thus, IRIS is a low-cost and effective technique for confirming the construction of chips down to block level. For example, IRIS can readily help determine if a chip has the correct amount of RAM, number of CPU cores, peripherals, bond pads, etc. This level of verification would be sufficient to deter most counterfeits or substitutions.

Linus has released the 6.8 kernel.

So it took a bit longer for the commit counts to come down this release than I tend to prefer, but a lot of that seemed to be about various selftest updates (networking in particular) rather than any actual real sign of problems. And the last two weeks have been pretty quiet, so I feel there's no real reason to delay 6.8.

Significant changes in this release include the deadline servers scheduling feature, support for memory-management auto-tuning in DAMON, the large anonymous folios feature, the kernel samepage merging advisor, the ability to prevent writes to block devices containing mounted filesystems, the listmount() and statmount() system calls, the first device driver written in Rust, the removal of the (never finished) bpfilter packet-filtering system, three new system calls for managing Linux security modules, support for data-type profiling in the perf tool, guest-first memory for KVM virtualization, the Intel Xe graphics driver, and a lot more. See the LWN merge-window summaries (part 1, part 2) for more information.

The 6.8 kernel was released on March 10 after a typical, nine-week development cycle. Over this time, 1,938 developers contributed 14,405 non-merge changesets, making 6.8 into a slower cycle than 6.7 (but busier than 6.6), with the lowest number of developers participating since the 6.5 release. Still, there was a lot going on during this cycle; read on for some of the details.

Geoff Huston digs into the details of the KeyTrap DNS vulnerability, which was disclosed in February.

It's by no means "[devastating]" for the DNS, and the fix is much the same as the previous fix. As well as limiting the number of queries that a resolver can generate to resolve a queried name, a careful resolver will limit both the elapsed time and perhaps the amount of the resolver's processing resources that are used to resolve any single query name.

It's also not a novel discovery by the ATHENE folk. The vulnerability was described five years ago by a student at the University of Twente. I guess the issue was that the student failed to use a sufficient number of hysterical adjectives in describing this DNS vulnerability in the paper!