Hírolvasó

Today's stable kernel updates are 5.15.11, 5.10.88, 5.4.168, 4.19.222, 4.14.259, 4.9.294, and 4.4.296. Each contains another set of important fixes.

Security updates have been issued by CentOS (firefox, ipa, log4j, and samba), Debian (sogo, spip, and xorg-server), Fedora (jansi and log4j), Mageia (apache, apache-mod_security, kernel, kernel-linus, and x11-server), openSUSE (log4j and xorg-x11-server), Oracle (kernel, log4j, and openssl), and SUSE (libqt4 and xorg-x11-server).

Fedora is among the group of Linux distributions that, by default, lock out the root account such that it does not have a password and cannot be logged into. But, traditionally, "rescue mode" boots the system into single-user mode, which requires a root password—difficult to provide if it does not exist. A Fedora proposal to remove the need for the password in that case, and just drop into a root shell, does not seem likely to go far in that form, but it would seem to have pointed toward some better solutions for the underlying problem.

The Linux Foundation has announced the posting of a report on its research into diversity, equity, and inclusion in open-source communities.

The research shows that while a majority of respondents feel welcome in open source, many in underrepresented communities do not. We hope that the data and insights that this project provides will be a catalyst for strengthening existing DEI initiatives and creating new ones.

The full report can be downloaded from this page.

Security updates have been issued by Mageia (log4j), openSUSE (chromium, log4j, netdata, and nextcloud), Oracle (kernel and kernel-container), Red Hat (kernel, kernel-rt, log4j, openssl, postgresql:12, postgresql:13, and virt:rhel and virt-devel:rhel), Slackware (httpd), SUSE (xorg-x11-server), and Ubuntu (firefox).

A clarion call from the Electronic Frontier Foundation (EFF) warning about upcoming changes to the Chrome browser's extension API was not the first such—from the EFF or from others. The time of the switch to Manifest V3, as the new API is known, is growing closer; privacy advocates are concerned that it will preclude a number of techniques that browser extensions use for features like ad and tracker blocking. Part of the concern stems from the fact that Google is both the developer of a popular web browser and the operator of an enormous advertising network so its incentives seem, at least, plausibly misaligned.

The CONFIG_RCU_FAST_NO_HZ Kconfig option was added many years ago to improve energy efficiency for systems having significant numbers of short bursts of idle time. Prior to the addition of CONFIG_RCU_FAST_NO_HZ, RCU would insist on keeping a given idle CPU's scheduling-clock tick enabled until all of that CPU's RCU callbacks had been invoked. On certain types of battery-powered embedded systems, these few additional scheduling-clock ticks would consume up to 40% of the battery lifetime. The people working on such systems were not amused, and were not shy about letting me know of their dissatisfaction with RCU's life choices. Please note that “letting me know” did not take the form of flaming me on LKML. Instead, they called me on the telephone and yelled at me.

Given that history, why on earth would I even be thinking about removing CONFIG_RCU_FAST_NO_HZ, let alone queuing a patch series intended for the v5.17 merge window???

The reason is that everyone I know of who builds their kernels with CONFIG_RCU_FAST_NO_HZ=y also boots those systems with each and every CPU designated as a rcu_nocbs CPU. With this combination, CONFIG_RCU_FAST_NO_HZ=y is doing nothing but placing a never-taken branch in the fastpath to and from idle. Such systems should therefore run slightly faster and with slightly better battery lifetime if their kernels were instead built with CONFIG_RCU_FAST_NO_HZ=n, which would get rid of that never-taken branch.

But given that battery-powered embedded folks badly wanted CONFIG_RCU_FAST_NO_HZ=y, and given that they are no longer getting any benefit from it, why on earth haven't they noticed?

The have not noticed because rcu_nocbs CPUs do not invoke their own RCU callbacks. This work is instead delegated to a set of per-CPU rcuoc kthreads, with a smaller set of rcuog kthreads managing those callbacks and requesting grace periods as needed. By default, these rcuoc and rcuog kthreads are not bound, which allows both the scheduler (and for that matter, the systems administrator) to take both performance and energy efficiency into account and to run those kthreads wherever is appropriate at any given time. In contrast, non-rcu_nocbs CPUs will always run their own callbacks, even if that means powering up an inconveniently placed portion of the system at an inconvenient time. This includes CONFIG_RCU_FAST_NO_HZ=y kernels, whose only advantage is that they power up inconveniently placed portions of systems at inconvenient times only 25% as often as would a non-rcu_nocbs CPU in a CONFIG_RCU_FAST_NO_HZ=n kernel.

In short, the rcu_nocbs CPUs' practice of letting the scheduler decide where to run the callbacks is especially helpful on asymmetric systems (AKA big.LITTLE systems), as shown by data collected by Dietmar Eggeman and Robin Randhawa. This point is emphasized by the aforementioned fact that everyone I know of who builds their kernels with CONFIG_RCU_FAST_NO_HZ=y also boots those systems with each and every CPU designated as a rcu_nocbs CPU.

So if no one is getting any benefit from building their kernels with CONFIG_RCU_FAST_NO_HZ=y, why keep that added complexity in the Linux kernel? Why indeed, and hence the patch series intended for the v5.17 merge window.

So if you know of someone who is getting significant benefit from CONFIG_RCU_FAST_NO_HZ=y who could not get that benefit from booting with rcu_nocbs CPUs, this would be a most excellent time to let me know!

Techdirt looks at the problem of copyleft trolls, and those who target users of Creative Commons materials in particular.

However, in the end, they are still licenses, and those licenses are still backed by copyright -- which means that if you don't abide by the specifics of the Creative Commons license, you could very much be liable for copyright infringement. Enter the copyleft trolls. They search for those using CC-licensed works, but not following the exact terms of the license, and then resort to the typical copyright troll shakedown game.

Security updates have been issued by Debian (apache-log4j2, firefox-esr, libssh2, modsecurity-apache, and tang), Fedora (lapack, log4j, rust-libsqlite3-sys, rust-rusqlite, xorg-x11-server, and xorg-x11-server-Xwayland), Mageia (bind, botan2, chromium-browser-stable, dovecot, hiredis, keepalived, log4j, matio, mediawiki, olm, openssh, pjproject, privoxy, vim, and watchdog), openSUSE (barrier, nim, and python-pip), Oracle (ipa and samba), Scientific Linux (ipa and samba), SUSE (log4j), and Ubuntu (apache-log4j2, htmldoc, python3.6, python3.7, python3.8, and python3.8, python3.9).

Damien Miller (djm@) just noted on social media that he has committed (starting here) changes which allow control over ssh-agent(1) key-forwarding based on destination host and forwarding path.

A detailed description is available on the OpenSSH site.

After much preparatory work in base and ports, clang(1) has been upgraded to version 13.0.0 (on the relevant platforms).

Patrick Wildt (patrick@) made the commits.

The 5.16-rc6 kernel prepatch is out for testing.

Regardless of what happens, I will be making an rc8 - not because this release looks particularly problematic, but simply due to the seasonal holidays. There's no point in releasing a final 5.16 and opening the merge window when people are still on holiday or just coming back. So we'll have at least one extra week of rc this release, even if no nasty issues appear.

Just in time for the upcoming holidays, "KDE's educational suite of more than 170 activities and pedagogical games", GCompris, has released version 2.0. It includes new and updated games and activities, including: Getting back to numeracy activities, GCompris 2.0 includes a wide range of activities that mimic basic manipulation math games, allowing young players to experiment with elements, grouping them in sets of up to ten items. This helps them build a clear concept of the decimal system, and, as with many GCompris activities, an educator can gradually increase the difficulty level, allowing the activities to be used with children of ages between 3 and 10. Once they grasp the concept of the decimal system, the addition and subtraction activities, also based on math manipulation, help practice arithmetic.

Along with other classics, like chess, align four, and checkers, fans of strategy games will enjoy Oware, a game that requires forethought and, again, numeracy skills. Oware is originally a traditional African pastime and can be played against a friend or against Tux, offering unlimited hours of fun.

The Google Security Blog looks into the ripple effects of the Log4j vulnerability.

Most artifacts that depend on log4j do so indirectly. The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs. For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.

There are some parts of the kernel where even the most experienced and capable developers fear to tread; one of those is surely the code that implements signals. The nature of the signal API almost guarantees that any implementation will be full of subtle interactions and complexities, and the version in Linux doesn't disappoint. So the inclusion of a signal-handling change late in the 5.16 merge window might have been expected to have the potential for difficulties; it didn't disappoint either.

Greg Kroah-Hartman has announced the release of the 5.15.10, 5.10.87, and 5.4.167 stable kernels. These are fairly small updates, but, unlike yesterday's single self-test bug fix updates, do contain important fixes throughout the tree; users should upgrade.

Security updates have been issued by Debian (kernel), Fedora (dr_libs, libsndfile, and podman), openSUSE (fetchmail, log4j, log4j12, logback, python3, and seamonkey), Oracle (go-toolset:ol8, idm:DL1, and nodejs:16), Red Hat (go-toolset-1.16 and go-toolset-1.16-golang, ipa, rh-postgresql12-postgresql, rh-postgresql13-postgresql, and samba), Slackware (xorg), SUSE (log4j, log4j12, and python3), and Ubuntu (apache-log4j2 and openjdk-8, openjdk-lts).

The 5.15.9, 5.10.86, and 5.4.166 stable kernels have been released. "Only change here is a permission setting of a netfilter selftest file. No need to upgrade if this problem is not bothering you."

By now, most readers will likely have seen something about the Log4j vulnerability that has been making life miserable for system administrators since its disclosure on December 9. This bug is relatively easy to exploit, results in remote code execution, and lurks on servers all across the net; it is not hyperbolic to call it one of the worst vulnerabilities that has been disclosed in some years. In a sense, the lessons from Log4j have little new to teach us, but this bug does highlight some problems in the free-software ecosystem in an unambiguous way.

Security updates have been issued by Debian (apache-log4j2 and mediawiki), Fedora (libmysofa, libolm, and vim), Oracle (httpd), Red Hat (go-toolset:rhel8), and Ubuntu (apache-log4j2 and mumble).