Linux Weekly News

Non-uniform memory access (NUMA) systems have an architecture that attaches memory to "nodes" within the system. CPUs, too, belong to nodes; memory that is attached to the same node as a CPU will be faster to access (from that CPU) than memory on other nodes. This aspect of performance has important implications for programs running on NUMA systems, and the kernel offers a number of ways for user space to optimize their behavior. The NUMA abstraction is now being extended, though, and that is driving a need for new ways of influencing memory allocation; the multi-preference memory policy patch set is an attempt to meet that need.

Security updates have been issued by CentOS (firefox), Debian (firefox-esr), Fedora (linuxptp), Gentoo (commons-collections), Mageia (aom, firefox, python-django, thunderbird, and tpm2-tools), openSUSE (claws-mail, kernel, nodejs10, and nodejs14), Red Hat (nettle), Scientific Linux (firefox), SUSE (firefox, kernel, nodejs10, and nodejs14), and Ubuntu (libslirp and qemu).

Your editor has worked in the computing field for rather longer than he cares to admit; for all of that time it has been said that a day will come when all that tedious programming work will no longer be necessary. Instead, we'll just say what we want and the computer will figure it out. Arguably, the announcement of GitHub Copilot takes us another step in that direction. On the way, though, it raises some interesting questions about copyright and free-software licensing.

Security updates have been issued by Debian (firefox-esr and php7.0), Fedora (firefox, mingw-djvulibre, and seamonkey), Gentoo (fluidsynth, openscad, and urllib3), openSUSE (ffmpeg, nodejs12, and sqlite3), Red Hat (firefox), and SUSE (ffmpeg, kernel, nodejs10, nodejs12, nodejs14, and sqlite3).

For those who appreciate detailed descriptions of how to exploit a kernel vulnerability, this report on a netfilter bug by Andy Nguyen should certainly satisfy.

CVE-2021-22555 is a 15 years old heap out-of-bounds write vulnerability in Linux Netfilter that is powerful enough to bypass all modern security mitigations and achieve kernel code execution. It was used to break the kubernetes pod isolation of the kCTF cluster and won 10000$ for charity (where Google will match and double the donation to 20000$).

The LWN.net Weekly Edition for July 15, 2021 is available.

CentOS 8 is reaching its end of life (EOL) at the end of 2021, though it was originally slated to be supported until 2029. That change was announced last December, but it may still come as a surprise to some, perhaps many, of the users of the distribution. While the systems running CentOS 8 will continue to do so, early next year they will stop getting security (and other) updates. The CentOS project sees CentOS Stream as a viable alternative, but users may not agree—should the project simply leave CentOS 8 systems as ticking time bombs in 2022 and beyond?

The 5.13.2, 5.12.17, 5.10.50, and 5.4.132 stable kernel updates are out. They are huge; when asked why, Greg Kroah-Hartman responded:

They show the problem that we currently have where maintainers wait at the end of the -rc cycle and keep valid fixes from being sent to Linus. They "bunch up" and come out only in -rc1 and so the first few stable releases after -rc1 comes out are huge. It's been happening for the past few years and only getting worse. These stable releases are proof of that, the 5.13.2-rc release was the largest we have ever done and it broke one of my scripts because of it :(

There has been more than the usual amount of discussion about patches that perhaps should not have been included; the probability of regressions in these releases may be a bit above average. They also, of course, contain a lot of important bug fixes.

Security updates have been issued by CentOS (xstream), Debian (linuxptp), Fedora (glibc and krb5), Gentoo (pillow and thrift), Mageia (ffmpeg and libsolv), openSUSE (kernel and qemu), SUSE (kernel), and Ubuntu (php5, php7.0).

The Linux kernel is, as a whole, licensed under the GPLv2, but various parts and pieces are licensed under other compatible licenses and/or dual-licensed. That picture was much murkier only a few years back, before the SPDX in the kernel project cleaned up the licensing information in most of the kernel source by specifying the licenses, by name rather than boilerplate text, directly in the files. A recent move to add yet another license into the mix is encountering some headwinds, but the license in question was already being used in a few kernel files, and has been for four years at this point.

Version 90 of the Firefox browser is out. The headline feature this time around, beyond working links in PDF output, is a new version of the SmartBlock feature which appears to have been designed with a specific goal in mind: "Third-party Facebook scripts are blocked to prevent you from being tracked, but are now automatically loaded 'just in time' if you decide to 'Log in with Facebook' on any website."

Tails is a privacy focused distribution and Tails 4.20 "completely changes how to connect to the Tor network from Tails" with the new Tor Connection assistant. This new assistant is most useful for users who are at high risk of physical surveillance, under heavy network censorship, or on a poor Internet connection:

• It protects better the users who need to go unnoticed if using Tor could look suspicious to someone who monitors their Internet connection (parental control, abusive partner, school or work network, etc.).

• It allows people who need to connect to Tor using bridges to configure them without having to change the default configuration in the Welcome Screen.

• It helps first-time users understand how to connect to a local Wi-Fi network.

• It provides feedback while connecting to Tor and helps troubleshoot network problems.

Security updates have been issued by Debian (sogo), Fedora (libvirt), Gentoo (polkit), Mageia (binutils, freeradius, guile1.8, kernel, kernel-linus, libgrss, mediawiki, mosquitto, php-phpmailer, and webmin), openSUSE (bluez and jdom2), Oracle (kernel and xstream), Scientific Linux (xstream), and SUSE (kernel and python-pip).

The 5.14 merge window closed with the 5.14-rc1 release on July 11. By that time, some 12,981 non-merge changesets had been pulled into the mainline repository; nearly 8,000 of those arrived after the first LWN 5.14 merge-window summary was written. This merge window has thus seen fewer commits than its predecessor, which saw 14,231 changesets before the 5.13-rc1 release. That said, there is still a lot of interesting work that has found its way into the kernel this time around.

Security updates have been issued by Fedora (djvulibre), Gentoo (connman, gnuchess, openexr, and xen), openSUSE (arpwatch, avahi, dbus-1, dhcp, djvulibre, freeradius-server, fribidi, gstreamer, gstreamer-plugins-bad, gstreamer-plugins-base, gstreamer-plugins-good, gstreamer-plugins-ugly, gupnp, hivex, icinga2, jdom2, jetty-minimal, kernel, kubevirt, libgcrypt, libnettle, libxml2, openexr, openscad, pam_radius, polkit, postgresql13, python-httplib2, python-py, python-rsa, qemu, redis, rubygem-actionpack-5_1, salt, snakeyaml, squid, tpm2.0-tools, and xstream), Red Hat (xstream), and SUSE (bluez, csync2, dbus-1, jdom2, postgresql13, redis, slurm_20_11, and xstream).

Version 4.3 of the Solus "home computing" distribution has been released. "This release delivers new desktop environment updates, software stacks, and hardware enablement."

Linus has released 5.14-rc1 and closed the merge window for this development cycle:

On the whole, I don't think there are any huge surprises in here, and size-wise this seems to be a pretty regular release too. Let's hope that that translates to a nice and calm release cycle, but you never know.

The 5.12.16, 5.10.49, 5.4.131, 4.19.197, 4.14.239, 4.9.275, and 4.4.275 stable kernels have been released. Each contains a relatively small set of important fixes.

Security updates have been issued by Arch Linux (gitlab, nodejs, openexr, php, php7, rabbitmq, ruby-addressable, and spice), Fedora (suricata), Gentoo (binutils, docker, runc, and tor), Mageia (avahi, botan2, connman, gstreamer1.0-plugins, htmldoc, jhead, libcroco, libebml, libosinfo, openexr, php, php-smarty, pjproject, and python), openSUSE (apache2, bind, bouncycastle, ceph, containerd, docker, runc, cryptctl, curl, dovecot23, firefox, graphviz, gstreamer-plugins-bad, java-1_8_0-openj9, java-1_8_0-openjdk, libass, libjpeg-turbo, libopenmpt, libqt5-qtwebengine, libu2f-host, libwebp, libX11, lua53, lz4, nginx, ovmf, postgresql10, postgresql12, python-urllib3, qemu, roundcubemail, solo, thunderbird, ucode-intel, wireshark, and xterm), and SUSE (permissions).

The Tor project, which provides tools for internet privacy and anonymity, has announced a rewrite of the Tor protocols in Rust, called Arti. It is not ready for prime time, yet, but based on a grant from Zcash Open Major Grants (ZOMG), significant work is ongoing; the plan is "to try bring Arti to a production-quality client implementation over the next year and a half". The C implementation is not going away anytime soon, but the idea is that Arti will eventually supplant it. The project sees a number of benefits from using Rust, including: For years now, we've wanted to split Tor's relay cryptography across multiple CPU cores, but we've run into trouble. C's support for thread-safety is quite fragile, and it is very easy to write a program that looks safe to run across multiple threads, but which introduces subtle bugs or security holes. If one thread accesses a piece of state at the same time that another thread is changing it, then your whole program can exhibit some truly confusing and bizarre bugs.

But in Rust, this kind of bug is easy to avoid: the same type system that keeps us from writing memory unsafety prevents us from writing dangerous concurrent access patterns. Because of that, Arti's circuit cryptography has been multicore from day 1, at very little additional programming effort.