lwn.net

Security updates have been issued by CentOS (kernel), Debian (ghostscript, mesa, and postgresql-common), Fedora (chromium, php-robrichards-xmlseclibs, php-robrichards-xmlseclibs3, samba, scap-security-guide, and wpa_supplicant), Mageia (cpio, fribidi, libapreq2, python-numpy, webkit2, and zeromq), openSUSE (ImageMagick, kernel, libtomcrypt, qemu, ucode-intel, and xen), Oracle (kernel), Red Hat (ghostscript, kernel, and kernel-rt), Scientific Linux (ghostscript and kernel), SUSE (bash, enigmail, ghostscript, ImageMagick, kernel, libjpeg-turbo, openconnect, and squid), and Ubuntu (ghostscript, imagemagick, and postgresql-common).

Kees Cook catches up with the security improvements in the 5.3 kernel. "In recent exploits, one of the steps for making the attacker’s life easier is to disable CPU protections like Supervisor Mode Access (and Execute) Prevention (SMAP and SMEP) by finding a way to write to CPU control registers to disable these features. For example, CR4 controls SMAP and SMEP, where disabling those would let an attacker access and execute userspace memory from kernel code again, opening up the attack to much greater flexibility. CR0 controls Write Protect (WP), which when disabled would allow an attacker to write to read-only memory like the kernel code itself. Attacks have been using the kernel’s CR4 and CR0 writing functions to make these changes (since it’s easier to gain that level of execute control), but now the kernel will attempt to 'pin' sensitive bits in CR4 and CR0 to avoid them getting disabled. This forces attacks to do more work to enact such register changes going forward."

The Yocto Project recently announced its 3.0 release, maintaining the spring/fall cadence it has followed for the past nine years. As well as the expected updates, it contains new thinking on getting the best of two worlds: source builds and prebuilt binaries. This fits well into a landscape where reproducibility and software traceability, all the way through to device updates, are increasingly important to handle complex security issues.

Security updates have been issued by Arch Linux (kernel, linux-lts, and linux-zen), CentOS (kernel, sudo, and thunderbird), Debian (linux-4.9), Fedora (samba), openSUSE (apache2-mod_auth_openidc, kernel, qemu, rsyslog, and ucode-intel), Oracle (kernel), Red Hat (kernel and kernel-rt), Scientific Linux (kernel), SUSE (kernel and microcode_ctl), and Ubuntu (kernel, libjpeg-turbo, linux, linux-hwe, linux-oem, linux, linux-hwe, linux-oem-osp1, and qemu).

The LWN.net Weekly Edition for November 14, 2019 is available.

Digging into the email that provides the cornerstone of Linux kernel development is an endeavor that has become more popular over the last few years. There are some practical reasons for analyzing the kernel mailing lists and for correlating that information with the patches that actually reach the mainline, including tracking the path that patches take—or don't take. Three researchers reported on some efforts they have made on kernel email analysis at the 2019 Embedded Linux Conference Europe (ELCE), held in late October in Lyon, France.

The Bytecode Alliance is an industry partnership with the aim of forging WebAssembly’s outside-the-browser future by collaborating on implementing standards and proposing new ones. The newly formed alliance has "a vision of a WebAssembly ecosystem that is secure by default, fixing cracks in today’s software foundations". The alliance is currently working on a standalone WebAssembly runtime, two use-case specific runtimes, runtime components, and language tooling.

This year saw the second edition of the Automated Testing Summit (ATS) and the first that was open to all. Last year's ATS was an invitation-only gathering of around 35 developers (that was described in an LWN article), while this year's event attracted around 50 attendees; both were held in conjunction with the Embedded Linux Conference Europe (ELCE), in Edinburgh, Scotland for 2018 and in Lyon, France this year. The basic problem has not changed—more collaboration is needed between the different kernel testing systems—but the starting points have been identified and work is progressing, albeit slowly. Part of the problem, of course, is that all of these testing efforts have their own constituencies and customers, who must be kept up and running, even while any of this collaborative development is going on.

Security updates have been issued by Debian (dpdk, intel-microcode, kernel, libssh2, qemu, and webkit2gtk), Fedora (apache-commons-beanutils, bluez, iwd, kernel, kernel-headers, kernel-tools, libell, and microcode_ctl), openSUSE (gdb), Oracle (kernel), Red Hat (kernel and kernel-rt), SUSE (dhcp, evolution, kernel, libcaca, python, python-xdg, qemu, sysstat, ucode-intel, and xen), and Ubuntu (dpdk, intel-microcode, kernel, linux, linux-aws, linux-kvm, linux, linux-lts-trusty, linux-azure, linux-hwe, linux-kvm, linux-oem, linux-oracle, linux-kvm, linux-oem-osp1, linux-oracle, linux-raspi2, linux-lts-xenial, linux-aws, linux-raspi2, and webkit2gtk).

A set of patches has just been pushed into the mainline repository (and stable updates) for yet another set of hardware vulnerabilities. "TSX async abort" (or TAA) exposes information through the usual side channels by way of internal buffers used with the transactional memory (TSX) instructions. Mitigation is done by disabling TSX or by clearing the relevant buffers when switching between kernel and user mode. Given that this is not the first problem with TSX, disabling it entirely is recommended; a microcode update may be needed to do so, though. This commit contains documentation on this vulnerability and its mitigation.

There are also fixes for another vulnerability: it seems that accessing a memory address immediately after the size of the page containing it was changed (from a regular to a huge page, for example) can cause the processor to lock up. This behavior is considered undesirable by many. The vulnerability only exists for pages marked as executable; the mitigation is to force all executable pages to be the regular, 4K page size.

Stable kernels 5.3.11, 4.19.84, 4.14.154, 4.9.201, and 4.4.201 have been released. They all contain important fixes and users should upgrade.

Security updates have been issued by Fedora (community-mysql, crun, java-latest-openjdk, and mupdf), openSUSE (libssh2_org), and SUSE (go1.12, libseccomp, and tar).

Many community-based Linux distributions have made the decision to switch to systemd, and most of those decisions were accompanied by lengthy, sometimes acrimonious mailing-list discussions. No distribution had a harder time of it than Debian, though, where arguments raged through much of 2013 before the Debian Technical Committee decided on systemd in early 2014. Thereafter, it is fair to say, appetite for renewing the init-system discussion has been low. Now, though, the topic has returned to the fore and it would appear that the project is heading toward a new general resolution to decide at what level init systems other than systemd should be supported.

The Free Software Foundation's Respects Your Freedom program provides a certification for hardware that supports your freedom. A new website listing certified products has been launched. "In 2012, when we announced the first certification, we hosted information about the program and retailers as a simple page on the Free Software Foundation (FSF) Web site. With only one retailer selling one device, this was certainly satisfactory. As the program grew, we added each new device chronologically to that page, highlighting the newest certifications. We are now in a place where eight different retailers have gained nearly fifty certifications [...]. With so many devices available, across so many different device categories, it was getting more difficult for users to find what they were looking for in just a plain chronological list."

Stable kernels 5.3.10, 4.19.83, 4.14.153, 4.9.200, and 4.4.200 have been released. They all contain important fixes and users should upgrade.

Security updates have been issued by Debian (ampache, chromium, djvulibre, firefox-esr, gdal, and ruby-haml), Fedora (chromium, file, gd, hostapd, nspr, and rssh), openSUSE (bcm20702a1-firmware, firefox, gdal, libtomcrypt, php7, python-ecdsa, python3, samba, and thunderbird), SUSE (apache2-mod_auth_openidc, libssh2_org, and rsyslog), and Ubuntu (bash).

The seventh 5.4 prepatch is out for testing. "Nothing looks _bad_, but there is too much of it. So I'm leaning towards an rc8 being likely next weekend due to that, but I won't make a final decision yet. We'll see."

Operating systems and computing hardware both carry a lot of their history with them. The x86 I/O-port mechanism is one piece of that history; it is rarely used by hardware designed in the last 20 years, but it must still be supported. That doesn't mean that this support can't be cleaned up and improved, though, especially when the old implementation turns out to have some unpleasant properties. An example can be seen in the iopl() patch set from Thomas Gleixner.

The openSUSE project has been considering a name change as part of its move into a separate foundation since (at least) June. A long and somewhat controversial vote of project members has just come to an end, and the result is conclusive: 225-42 against the name change.

Security updates have been issued by Arch Linux (linux-hardened), Debian (fribidi), Gentoo (oniguruma, openssh/openssh, openssl, and pump), Mageia (chromium-browser-stable, expat, firefox, freetds, proftpd, python, thunderbird, and unbound), Oracle (sudo), Scientific Linux (thunderbird), Slackware (kernel), SUSE (rubygem-haml), and Ubuntu (fribidi and webkit2gtk).