from Johannes Weiner seemed like a straightforward way to improve
memory-reclaim performance; without it, the virtual filesystem layer throws
away memory that the memory-management subsystem thinks is still worth
keeping. But that patch quickly ran afoul of a feature (or "misfeature"
depending on who one asks) from the distant past,
one which goes by the name of "high memory". Now, more than 20 years after its
addition, high memory may be
brought down low, as developers consider whether it should be deprecated
and eventually removed from the kernel altogether.
Security updates have been issued by CentOS (kernel, ksh, python-pillow, and thunderbird), Debian (opensmtpd, proftpd-dfsg, and rake), Fedora (NetworkManager-ssh), openSUSE (chromium), and SUSE (libexif, mariadb, ovmf, python3, and squid).
The LWN.net Weekly Edition for February 27, 2020 is available.
The "kernel runtime security instrumentation" (KRSI) patch set has been
making the rounds over the past few months; the idea is to use the Linux
security module (LSM) hooks as a way to detect, and potentially deflect,
active attacks against a running system.
It does so by allowing BPF programs to be attached to the LSM hooks. That has
caused some concern
in the past about exposing the
security hooks as external kernel APIs, which makes them potentially
subject to the "don't break user space" edict. But
there has been no real objection
to the goals of KRSI. The fourth version
of the patch set was posted
by KP Singh on February 20; the concerns raised this time are about
its impact on the LSM infrastructure.
Security updates have been issued by Debian (python-pysaml2), Mageia (clamav, graphicsmagick, opencontainers-runc, squid, and xmlsec1), Oracle (kernel, ksh, python-pillow, systemd, and thunderbird), Red Hat (rh-nodejs12-nodejs), Scientific Linux (ksh, python-pillow, and thunderbird), and SUSE (nodejs6, openssl, ppp, and squid).
has exploded within the Linux world
over the last few years, growing
from its networking roots into the go-to tool for running custom
in-kernel programs. Its role seems to expand with every kernel release
into diverse areas such as security and device control. But none of that
is the focus of a relatively new book from Brendan Gregg, BPF
; it looks, instead, at how BPF provides visibility into
the guts of the kernel. Finding performance bottlenecks of
various sorts on (generally large) production systems is an area where BPF
and the tool set that has grown up around it can excel; Gregg's book
describes that landscape in great depth.
of the Arch-based Manjaro distribution is out.
"The Xfce edition remains our flagship offering and has received the
attention it deserves. Only a few can claim to offer such a polished,
integrated and leading-edge Xfce experience. With this release we ship Xfce
4.14 and have mostly focused on polishing the user experience with the
desktop and window manager. Also we have switched to a new theme called
Matcha. A new feature Display-Profiles allows you to store one or more
profiles for your preferred display configuration. We also have implemented
auto-application of profiles when new displays are connected.
The Free Software Foundation has announced
that it is planning to launch a public code hosting and collaboration
platform later this year. "We plan on contributing improvements
upstream for the new forge software we choose, to boost its score on [GNU
ethical repository] criteria. Our tech team is small for the size of the
network we maintain, and we don't have any full-time developers who work
for the FSF, so we are limited in the amount of time we can spend on the
software we choose. We'll communicate with the upstream developers to
request improvements and help clarify any questions related to the ethical
Security updates have been issued by Debian (curl and otrs2), Fedora (NetworkManager-ssh and python-psutil), Mageia (ipmitool, libgd, libxml2_2, nextcloud, radare2, and upx), openSUSE (inn and sudo), Oracle (kernel, ksh, python-pillow, and thunderbird), Red Hat (curl, kernel, nodejs:10, nodejs:12, procps-ng, rh-nodejs10-nodejs, ruby, and systemd), SUSE (dpdk, firefox, java-1_7_1-ibm, java-1_8_0-ibm, libexif, libvpx, nodejs10, nodejs8, openssl1, pdsh, slurm_18_08, python-azure-agent, python3, and webkit2gtk3), and Ubuntu (libapache2-mod-auth-mellon, libpam-radius-auth, and rsync).
Filesystems, by design, hide a lot of complexity from users. At times,
though, those users need to be able to look inside the black box and extract
information about what is going on within a filesystem. Answering this
need is David Howells, the creator of a number of filesystem-oriented
system calls; in this
he tries to add three more, one of which we have seen before
and two of which are new.
kernel prepatch is out for
testing. Linus says: "Fairly normal rc3 as far as I can tell. We've
seen bigger, but we've
seen smaller ones too. Maybe this is slightly on the low side of
average at this time, which would make sense since this was a smaller
merge window. Anyway, too much noise in the signal to be sure either
Stable kernels 5.5.6
, and 4.19.106
have been released. They all have a
large set of important fixes.
Security updates have been issued by Debian (libpam-radius-auth, pillow, ppp, proftpd-dfsg, and python-pysaml2), Fedora (firefox, glib2, hiredis, http-parser, libuv, mingw-openjpeg2, nghttp2, nodejs, openjpeg2, python-pillow, skopeo, and webkit2gtk3), Mageia (patch, postgresql, and systemd), Red Hat (ksh, nodejs:10, openjpeg2, python-pillow, systemd, and thunderbird), and SUSE (java-1_7_1-ibm, libsolv, libzypp, zypper, pdsh, slurm_18_08, and php53).
system call is a complicated beast, requiring a fair amount of study to
master. This call also has some interesting security implications: it can
be used to obtain a lot of information about the running system, and the
complexity of the underlying implementation has made it more than usually
prone to unpleasant bugs. In current kernels, the security controls around
are simple, though: if you have the
to you (though the system administrator can make it available without any
privilege at all). Some
current work to create a new capability for the perf events subsystem would
seem to make sense, raising the question of why adding new capabilities
isn't done more often.
Security updates have been issued by CentOS (openjpeg2), Debian (cloud-init, jackson-databind, and python-reportlab), Red Hat (ksh, python-pillow, systemd, and thunderbird), Slackware (proftpd), SUSE (java-1_7_0-ibm, nodejs10, and nodejs12), and Ubuntu (ppp and squid, squid3).
To a great extent, memory management is based on making predictions: which
pages of memory will a given process need in the near future?
Unfortunately, it turns out that predictions are hard, especially when they
are about future events. In the absence of useful information sent back from
the future, memory-management subsystems are forced to rely on observations
of recent behavior and an assumption that said behavior is likely
to continue. The kernel's memory-management decisions are
opaque to user space, though, and often result in less-than-optimal
performance. A pair of patch sets from SeongJae
Park tries to make memory-usage patterns visible to user space, and to let
user space change memory-management decisions in response.
Security updates have been issued by Debian (netty and netty-3.9), Fedora (ceph, dovecot, poppler, and webkit2gtk3), openSUSE (inn and rmt-server), Oracle (openjpeg2), Red Hat (rabbitmq-server), Scientific Linux (openjpeg2), SUSE (dnsmasq, rsyslog, and slurm), and Ubuntu (php7.0).
The LWN.net Weekly Edition for February 20, 2020 is available.
Stable kernels 5.5.5
, and 4.19.105
have been released, with the usual
set of important fixes.
At this point, most of the kernel work
the year-2038 apocalypse has been completed. Said apocalypse could occur when
time counted in seconds since 1970 overflows a 32-bit signed value
). Work in the GNU C Library (glibc) and other C
libraries is well
underway as well. But the "fun" is just beginning for distributions,
especially those that support 32-bit architectures, as a recent Debian
discussion reveals. One of the questions is: how much effort should be
made to support 32-bit architectures as they fade
from use and 2038 draws nearer?