A read-only filesystem that will transparently share file data between disparate directory trees, while also providing integrity verification for the data and the directory metadata, was recently posted as an RFC to the linux-kernel mailing list. Composefs was developed by Alexander Larsson (who posted it) and Giuseppe Scrivano for use by podman containers and OSTree (or "libostree" as it is now known) root directories, but there are likely others who want the abilities it provides. So far, there has been little response, either with feedback or complaints, but it is a small patch set (around 2K lines of code) and generally self-contained since it is a filesystem, so it would not be a surprise to see it appear in some upcoming kernel.

Security updates have been issued by Debian (cgal, ruby-rails-html-sanitizer, and xfce4-settings), Red Hat (dbus, grub2, kernel, pki-core, and usbguard), Scientific Linux (pki-core), SUSE (bcel, LibVNCServer, and xen), and Ubuntu (ca-certificates and u-boot).

Gccrs — the Rust front-end for GCC — has been approved for merging into the GCC trunk. That means that the next GCC release will be able to compile Rust, sort of; as gccrs developer Arthur Cohen warns: "This is very much an extremely experimental compiler and will still get a lot of changes in the coming weeks and months up until the release". See this article and this one for more details on the current status of gccrs.

Over on the Collabora blog, Adrian Ratiu writes about the addition of the kernel's Rust code to the KernelCI automated kernel testing project. The blog post looks at what it took to add the support and on some plans for future additions, as well. An interesting challenge for the rustc docker builds was the fact that the standard Rust method of installing toolchains is via curl https://sh.rustup.rs | sh which might be ok-ish for individual local development, but is a particularly bad idea in an automated CI system. Rustup itself does not (yet) do any signature verifications for its downloads.

Distros like Debian do not ship the version required by the kernel (v1.62), nor even rustup in some cases, and it's unlikely the distro maintainers will keep the versions in sync with the mainline kernel which likely will become a moving target. Thankfully the Rust project provides standalone installers together with GPG signatures which are very useful for CI.

The kernel's page cache holds pages from files in RAM, allowing those pages to be accessed without expensive trips to persistent storage. Applications are normally entirely unaware of the page cache's operation; it speeds things up and that is all that matters. Some applications, though, can benefit from knowledge about how much of a given file is present in the page cache at any given time; the proposed cachestat() system call from Nhat Pham is the latest in a long series of attempts to make that information available.

Security updates have been issued by Ubuntu (binutils and ca-certificates).

Alison Chaiken provides an overview of Linux ABI concerns on opensource.com.

Understanding the stable ABI is a bit subtle. Consider that, while most of sysfs is stable ABI, the debug interfaces are guaranteed to be unstable since they expose kernel internals to userspace. In general, Linus Torvalds has pronounced that by "don't break userspace," he means to protect ordinary users who "just want it to work" rather than system programmers and kernel engineers, who should be able to read the kernel documentation and source code to figure out what has changed between releases.

The kernel project is now more than three decades old; over that time, a number of development practices have come and gone. Once upon a time, the use of "magic numbers" to identify kernel data structures was seen as a good way to help detect and debug problems. Over the years, though, the use of magic numbers has gone into decline; this patch set from Ahelenia Ziemiańska may be an indication that the reign of magic numbers may be reaching its end.

Security updates have been issued by Debian (awstats, chromium, clamav, g810-led, giflib, http-parser, jhead, libpgjava, node-cached-path-relative, node-fetch, and vlc), Fedora (fastnetmon, kernel, librime, qpress, rr, thunderbird, and wireshark), Red Hat (kernel, kernel-rt, and kpatch-patch), Slackware (mozilla), SUSE (cherrytree and chromium), and Ubuntu (libbpf, libxml2, linux-gcp-5.15, linux-gke, linux-gke-5.15, and linux-gke).

The eighth and presumably final 6.1 kernel prepatch has been released for testing. "So everything looks good, and while the calming down may have happened later than I wished for, it did happen. Let's hope this upcoming week is as quiet (or quieter)."

The 6.0.11, 5.15.81, and 5.10.157 stable kernel updates have been released; each contains another set of important fixes.

The software-interrupt mechanism is one of the oldest parts in the kernel; arguably, the basic design behind it predates Linux itself. Software interrupts can get in the way of other work so, for almost as long as they have existed, developers have wished that they could be made to go away. That has never happened, though, and doesn't look imminent. Instead, Android systems have long carried a patch that tries to minimize the impact of software interrupts, at least in some situations. John Stultz is now posting that work, which contains contributions from a number of authors, in the hope of getting it into the mainline kernel.

Security updates have been issued by Debian (snapd), Fedora (firefox, libetpan, ntfs-3g, samba, thunderbird, and xen), SUSE (busybox, emacs, and virt-v2v), and Ubuntu (linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux, linux-aws, linux-dell300x, linux-gcp-4.15, linux-kvm, linux-oracle, linux-raspi2, linux-snapdragon, linux, linux-aws, linux-gcp, linux-ibm, linux-kvm, linux-lowlatency, linux-oracle, linux-raspi, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-aws-hwe, linux-gcp, linux-hwe, linux-oracle, and tiff).

Bleeping Computer reports that the Android platform signing certificates for several manufacturers have leaked and been used to sign malware.

However, based on the results, even though Google said that "all affected parties were informed of the findings and have taken remediation measures to minimize the user impact," it looks like not all the vendors have followed Google's recommendations since, at least in Samsung's case, the leaked platform certificates are still being used to digitally sign apps.

Over on the Google security blog, Jeffrey Vander Stoep writes about the impact of focusing on using memory-safe languages for new code in Android. As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.

While correlation doesn’t necessarily mean causation, it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code. This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. Of course there may be other contributing factors or alternative explanations. However, the shift is a major departure from industry-wide trends that have persisted for more than a decade (and likely longer) despite substantial investments in improvements to memory unsafe languages.

(Thanks to Rahul Sundaram.)

The Document Foundation (TDF) was created in 2010 to steward and support the development of the LibreOffice suite, which was then a new fork of OpenOffice.org. TDF has clearly been successful; unlike OpenOffice, which is currently under the Apache umbrella, LibreOffice is an actively developed and widely used project. But TDF has also been showing signs of stress in recent years, and the situation does not appear to be getting better. There are currently some significant disagreements over just what role TDF should play; if those cannot be resolved, there is a real chance that they could rip the Foundation apart.

Security updates have been issued by CentOS (device-mapper-multipath, firefox, hsqldb, krb5, thunderbird, and xorg-x11-server), Debian (libraw), Fedora (freerdp and grub2), SUSE (bcel, emacs, glib2, glibc, grub2, nodejs10, and tomcat), and Ubuntu (linux-azure-fde and snapd).

The LWN.net Weekly Edition for December 1, 2022 is available.

The recent discussion of a proposed change to the Python language—the usual fare on the language's Ideas forum—was interesting, somewhat less for the actual feature under discussion than for the other issues raised. The change itself is a minor, convenience feature that would provide a reproducible iteration order for certain kinds of sets between separate invocations of the interpreter. That is a pretty limited use case, and one that could perhaps be fulfilled in other ways, but the discussion also highlighted some potentially worrying trends in the way that feature ideas are handled in the Python community.

It was only a matter of time before somebody found a way to inject BPF into the CPU scheduler. This patch series, posted by Tejun Heo and containing work by David Vernet, Josh Don, and Barret Rhoden, does exactly that. The cover letter covers the motivation behind this work in detail:

One of our main goals was to lower the barrier to entry for experimenting with the scheduler. sched_ext provides ergonomic callbacks and helpers to ease common operations such as managing idle CPUs, scheduling tasks on arbitrary CPUs, handling preemptions from other scheduling classes, and more. While sched_ext does require some ramp-up, the complexity is self-contained, and the learning curve gradual. Developers can ramp up by first implementing simple policies such as global FIFO in only tens of lines of code, and then continue to learn the APIs and building blocks available with sched_ext as they build more featureful and complex schedulers.

There is a bit more documentation in this patch.