The kernel project merges dozens of drivers with every development cycle,
and almost every one of those drivers is entirely uncontroversial.
Occasionally, though, a driver submission raises wider questions, leading
to lengthy discussion and, perhaps, opposition. That is currently the case
with two separate drivers, both with ties to the networking subsystem. One
of them is hung up on questions of whether (and how) all device
functionality should be made available to user space, while the other has
run into turbulence because it drives a device that is unobtainable outside
of a single company.
Dirk Mueller has posted a
lengthy analysis of the XZ backdoor on the openSUSE News site, with a
focus on openSUSE’s response.
Debian, as well as the other affected distributions like openSUSE
are carrying a significant amount of downstream-only patches to
essential open-source projects, like in this case OpenSSH. With
hindsight, that should be another Heartbleed-level learning for the
work of the distributions. These patches built the essential steps
to embed the backdoor, and do not have the scrutiny that they
likely would have received by the respective upstream
maintainers. Whether you trust Linus Law or not, it was not even
given a chance to chime in here. Upstream did not fail on the
users, distributions failed on upstream and their users here.
The Earliest Virtual Deadline First (EEVDF)
scheduler was merged as an option for the 6.6 kernel. It represents a
major change to how CPU scheduling is done on Linux systems, but the EEVDF
front has been relatively quiet since then. Now, though, scheduler
developer Peter Zijlstra has returned from a long absence to post a patch
series intended to finish the EEVDF work. Beyond some fixes, this work
includes a significant behavioral change and a new feature intended to help
latency-sensitive tasks.
Security updates have been issued by AlmaLinux (kernel, less, libreoffice, nodejs:18, nodejs:20, rear, thunderbird, and varnish), Debian (pillow), Fedora (dotnet7.0), SUSE (sngrep, texlive-specs-k, tomcat, tomcat10, and xorg-x11-server), and Ubuntu (nss, squid, and util-linux).
The mainline kernel has just received a set of commits mitigating the
latest x86 hardware vulnerability, known as “branch history injection”.
From this commit:
Branch History Injection (BHI) attacks may allow a malicious
application to influence indirect branch prediction in kernel by
poisoning the branch history. eIBRS isolates indirect branch
targets in ring0. The BHB can still influence the choice of
indirect branch predictor entry, and although branch predictor
entries are isolated between modes when eIBRS is enabled, the BHB
itself is not isolated between modes.
See this commit for
documentation on the command-line parameter that controls this mitigation.
There are stable kernel releases (6.8.5, 6.6.26, 6.1.85,
and 5.15.154)
in the works that also contain the mitigations.
On February 20, Linaro held the initial
get-together for what is intended to be a regular Linux Kernel Forum for
the Arm-focused kernel community. This gathering aims to convene
approximately a few weeks prior to the merge window opening and prior to
the release of the current kernel version under development. Topics
covered in the first gathering include preparing 64-bit Arm kernels for
low-end embedded systems, memory errors and Compute Express
Link (CXL), devlink objectives, and scheduler integration.
Version 3.3.0 of the OpenSSL SSL/TLS implementation has been released.
Changes include a number of additions to its QUIC protocol support, some
year-2038 improvements for 32-bit systems, and a lot of cryptographic
features with descriptions like “Added a new EVP_DigestSqueeze()
API. This allows SHAKE to squeeze multiple times with different output
sizes.” See the release
notes for details.
Security updates have been issued by Debian (expat), Oracle (less and nodejs:20), Slackware (libarchive), SUSE (kubernetes1.23, nghttp2, qt6-base, and util-linux), and Ubuntu (python-django).
The Google Open Source Blog is carrying an
announcement for a new JPEG library called “Jpegli”. There are a
number of advantages claimed, including:
Jpegli can be encoded with 10+ bits per component. Traditional JPEG
coding solutions offer only 8 bit per component dynamics causing
visible banding artifacts in slow gradients. Jpegli’s 10+ bits
coding happens in the original 8-bit formalism and the resulting
images are fully interoperable with 8-bit viewers. 10+ bit dynamics
are available as an API extension and application code changes are
needed to benefit from it.
Sometimes the smallest patches create the biggest discussions. A case in
point would be the process by which the PostgreSQL community — not a group
normally prone to extended, strongly worded megathreads — resolved the question of
whether to merge a brief patch adding a new configuration parameter.
Sometimes, a proposal that looks like a security patch is not, in
fact, intended to be a security patch, but getting that point across can be
difficult.
Ok, so this rc3 looks a bit different than the usual ones, because
there’s a large series to bcachefs to do filesystem repair after
corruption. Not normally something we’d see in an rc kernel, but
hey, if you had a corrupted bcachefs filesystem you’d probably want
this, and if you thought bcachefs was stable already, I have a
bridge to sell you. Special deal only for you, real cheap.
OpenBSD 7.5 has been released. The list of changes and improvements is, as
usual, long; it includes the pinsyscalls() functionality covered
here in January.
Version 7.0 of the
FFmpeg audio/video toolkit is out. “The most noteworthy changes for
most users are a native VVC decoder (currently experimental, until more
fuzzing is done), IAMF support, or a multi-threaded ffmpeg CLI tool“.
There’s also the usual list of new formats and codecs, and a few deprecated
features have been removed.
Version
6.0 LTS of the Incus container management system has been released.
“This is a major milestone for Incus as it marks our first release with
extended support, suitable for use in production environments where monthly
feature releases aren’t suitable.” Changes include swap limits for
containers, a new shell completion mechanism, support for the creation of
VLAN interfaces, improved live migration, and more.
Obviously I’m kidding with the title here, but for GCC 14 I’ve
implemented a new warning: -Wanalyzer-infinite-loop that’s able to
detect some simple cases of infinite loops.
See also: this report from the 2023 GNU
Tools Cauldron.
The Rust programming language differs from C in many ways; those
differences tend to be what users admire in the language. But those
differences can also lead to an impedance mismatch when Rust code is
integrated into a C-dominated system, and it can be even worse in the
kernel, which is not a typical C program. Memory models are a case in
point. A programming language’s view of memory is sufficiently fundamental
and arcane that many developers never have to learn much about it. It is
hard to maintain that sort of blissful ignorance while working in the
kernel, though, so a recent discussion of how to choose a memory model for
kernel code in Rust is of interest.
The SUSE Security Team Blog is carrying a
detailed article on SUSE’s review of the KDE6 release.
The SUSE security team restricts the installation of system wide
D-Bus services and Polkit policies in openSUSE distributions and
derived SUSE products. Any package that ships these features needs
to be reviewed by us first, before it can be added to production
repositories.
In November, openSUSE KDE packagers approached us with a long list
of KDE components for an upcoming KDE6 major release. The packages
needed adjusted D-Bus and Polkit whitelistings due to renamed
interfaces or other breaking changes. Looking into this many
components at once was a unique experience that also led to new
insights, which will be discussed in this article.
The first stable release of Redict, a fork of the Redis in-memory database
under a copyleft license, has been announced.
You may be wondering why Redict would be of interest to you,
particularly when compared with Valkey,
another Redis fork that was announced on Thursday.
In technical terms, we are focusing on stability and long-term
maintenance, and on achieving excellence within our current
scope. We believe that Redict is near feature-complete and that it
is more valuable to our users if we take a conservative stance to
innovation and focus on long-term reliability instead. This is in
part a choice we’ve made to distinguish ourselves from Valkey,
whose commercial interests are able to invest more resources into
developing more radical innovations, but also an acknowledgement of
a cultural difference between our projects, in that the folks
behind Redict place greater emphasis on software with a finite
scope and ambitions towards long-term stability rather than
focusing on long-term growth in scope and complexity.
A common theme in early-days anti-Linux FUD was that, since anybody can
contribute to the code, it cannot be trusted. Over two decades later, one
rarely hears that line anymore; experience has shown that free-software
communities are not prone to shipping overtly hostile code. But, as the backdooring of XZ has reminded us, the
embedding of malicious code is, unfortunately, not limited to the
proprietary realm. Our community will be busy analyzing this incident for
some time to come, but clear conclusions may be hard to come by.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.