Linux Weekly News

In mid-February, we reported on the plan to unite the two kernel devices that provide random numbers; /dev/urandom was to effectively just be another way to access the random numbers provided by /dev/random. That change made it as far as the mainline during the Linux 5.18 merge window, but it was quickly reverted when problems were found. It may be possible to do that unification someday, but, for now, there are environments that need their random numbers early on—without entropy or the "Linus jitter dance" being available on the platform.

The Fedora 36 beta release has been announced.

Fedora 36 Workstation Beta includes GNOME 42, the newest release of the GNOME desktop environment. GNOME 42 includes a global dark style UI setting. It also has a redesigned screenshot tool. And many core GNOME apps have been ported to the latest version of the GTK toolkit, providing improved performance and a modern look.

If all goes well, the final Fedora 36 release will happen at the end of April.

Security updates have been issued by Debian (libdatetime-timezone-perl, pjproject, and tzdata), Mageia (chromium-browser-stable, docker, graphicsmagick, and libtiff), Oracle (expat), Red Hat (expat, httpd:2.4, openssl, and screen), Scientific Linux (expat and openssl), and Ubuntu (libtasn1-6, linux-oem-5.14, openjdk-lts, and paramiko).

A new set of vulnerabilities has been disclosed in the nftables subsystem; these lead fairly easily to a local system compromise, on some configurations at least. Fixes for these vulnerabilities were present in the March 28 stable updates; upgrading seems like a good idea.

Pointers are a fact of life for developers working in numerous languages. It is often convenient to be able to associate a small amount — a few bits at most — of ancillary information with a pointer. This can often be done within the pointer value itself with some careful masking and shifting. CPU manufacturers have been adding ways to support the addition of this sort of "tag" to pointers; the most recent may be AMD's "upper address ignore" (UAI) feature, support for which was recently posted by Bharata B Rao. This feature has an uncertain future in Linux, though, as the result of a fundamental design decision.

The Debian project has been voting on a general resolution that would allow secret voting on future issues. The results have been posted in unofficial form, and the winner was "proposal B": "Hide identities of Developers casting a particular vote and allow verification". One might think that closes the discussion, but Debian project leader candidate Felix Lechner is questioning the election and calling for it to be redone — something that the Debian constitution lacks provisions for.

Greg Kroah-Hartman has announced the release of new stable kernels: 5.17.1, 5.16.18, 5.15.32, 5.10.109, 5.4.188, 4.19.237, 4.14.274, and 4.9.309. They contain a relatively small set of important fixes throughout the three; users of those series should upgrade.

Security updates have been issued by Debian (chromium and faad2), Fedora (dotnet3.1, libass, linux-firmware, python-paramiko, seamonkey, and xen), openSUSE (perl-DBD-SQLite and wavpack), Slackware (seamonkey), SUSE (perl-DBD-SQLite and wavpack), and Ubuntu (binutils, python2.7, python3.4, python3.5, python3.6, python3.8, and smarty3).

As of this writing, 4,127 non-merge changesets have found their way into the mainline repository for the 5.18 development cycle. That may seem like a relatively slow start to the merge window, but there are a lot of changes packed into those commits. Read on for a summary of the most significant changes to land in the first half of the 5.18 merge window.

Security updates have been issued by Debian (tiff), Fedora (nicotine+ and openvpn), openSUSE (bind, libarchive, python3, and slirp4netns), Oracle (cyrus-sasl, httpd, httpd:2.4, and openssl), Red Hat (httpd and httpd:2.4), Scientific Linux (httpd), SUSE (bind, libarchive, python3, and slirp4netns), and Ubuntu (firefox).

Jann Horn describes in great detail the process he went through to exploit a tiny race window in the kernel.

Luckily for us, the race window contains the first few memory accesses to the struct file; therefore, by making sure that the struct file is not present in the fastest CPU caches, we can widen the race window by as much time as the memory accesses take. The standard way to do this is to use an eviction pattern / eviction set; but instead we can also make the cache line dirty on another core.

Over on the Collabora blog, Jason Ekstrand has a detailed look at writing a Vulkan graphics driver in today's world. "Not only has Vulkan grown, but Mesa has as well, and we've built up quite a suite of utilities and helpers for making writing Vulkan drivers easier." The blog post takes the form of a tutorial of sorts, though the end result is not a functioning Vulkan driver, the framework of one is shown. At the time we were developing ANV (the Intel Vulkan driver), the Vulkan spec itself was still under development and everything was constantly in flux. There were no best practices; there were barely even tools. Everyone working on Vulkan was making it up as they went because it was a totally new API. Most of the code we wrote was purpose-built for the Intel driver because there were no other Mesa drivers to share code. (Except for the short-lived LunarG Intel driver based in ilo, which we were replacing.) If we had tried to build abstractions, they could have gotten shot to pieces at any moment by a spec change. (We rewrote the descriptor set layout code from scratch at least five or six times before the driver ever shipped.) It was frustrating, exhausting, and a whole lot of fun.

These days, however, the Vulkan spec has been stable and shipping for six years, the tooling and testing situation is pretty solid, and there are six Vulkan drivers in the Mesa tree with more on the way. We've also built up a lot of common infrastructure. This is important both because it makes writing a Vulkan driver easier and because it lets us fix certain classes of annoying bugs in a common place instead of everyone copying and pasting those bugs.

The a.out executable format dates back to the earliest days of Linux — and before. It has not been used in any serious way for decades, but support still exists in the Linux kernel and has resisted all attempts at its removal. Back in January, Borislav Petkov tried yet again to delete support for this format, leading to another extended discussion. There is one difference this time around, though: the effort to get rid of a.out support might just succeed.

Security updates have been issued by Debian (php-twig), Mageia (abcm2ps, libpano13, and pesign), openSUSE (nextcloud and xen), Oracle (kernel, kernel-container, and openssl), SUSE (java-1_7_1-ibm and xen), and Ubuntu (linux-oem-5.14, openvpn, and thunderbird).

The LWN.net Weekly Edition for March 24, 2022 is available.

A recent discussion on the python-ideas mailing list gives some insight into how to—or how not to—propose a feature to be added to the language. At first blush, adding a method to Python's immutable tuple type for replacing one of its elements is not a particularly strange idea, nor one that would cause much in the way of backward-compatibility concerns. Even though there was some evidence offered that such a method might be useful, it seems pretty unlikely that the idea will go anywhere, at least in part because of the repetitive, bordering on aggressive, manner in which its benefits were argued.

Version 42 of the GNOME desktop environment is out.

This release introduces Dark mode and an entirely new screenshot workflow. Beyond that, there are several improved Settings panels, many of the GNOME applications have been ported to GTK 4 and libadwaita, and much more.

See the release notes for more information.

The 5.16.17, 5.15.31, 5.10.108, 5.4.187, 4.19.236, 4.14.273, and 4.9.308 stable kernels have all been released; each contains another set of important fixes.

Security updates have been issued by Mageia (cyrus-sasl, openssl, sphinx, and swtpm), openSUSE (qemu), Red Hat (expat, rh-mariadb103-mariadb, and rh-mariadb105-mariadb), SUSE (apache2, binutils, java-1_7_0-ibm, kernel-firmware, nodejs12, qemu, and xen), and Ubuntu (ckeditor and linux, linux-aws, linux-kvm, linux-lts-xenial).

Three candidates have thrown their hat into the ring as candidates for the 2022 Debian project leader (DPL) election. One is Jonathan Carter, who is now in his second term as DPL, while the other two are Felix Lechner and Hideki Yamane. As is the norm, the candidates self-nominated during the nomination period and are now in the campaigning phase until April 1. The vote commences April 2 and runs for two weeks; the results will be announced shortly thereafter and the new DPL term will start on April 21. The candidates have put out platforms and are fielding questions from the voters, Debian developers, thus it seems like a good time to look in on the election.