All posts by corbet

[$] The first half of the 4.19 merge window

Post Syndicated from corbet original https://lwn.net/Articles/762566/rss

As of this writing, Linus Torvalds has pulled just over 7,600 non-merge
changesets into the mainline repository for the 4.19 development cycle.
4.19 thus seems to be off to a faster-than-usual start, perhaps because the
one-week delay in the opening of the merge window gave subsystem
maintainers a bit more time to get ready. There is, as usual, a lot of
interesting new code finding its way into the kernel, along with the usual
stream of fixes and cleanups.

[$] Meltdown strikes back: the L1 terminal fault vulnerability

Post Syndicated from corbet original https://lwn.net/Articles/762570/rss

The Meltdown CPU vulnerability, first disclosed in early January, was frightening
because it allowed unprivileged attackers to easily read arbitrary memory
in the system. Spectre, disclosed at the same time, was harder to exploit
but made it possible for guests running in virtual machines to attack the
host system and other guests. Both vulnerabilities have been mitigated to
some extent
(though it will take a long time to even find
all of the Spectre
vulnerabilities
, much less protect against them). But now the newly
disclosed
“L1 terminal fault” (L1TF) vulnerability
(also going by the name Foreshadow) brings back both
threats: relatively
easy attacks against host memory from inside a guest. Mitigations are
available (and have been merged
into the mainline kernel
), but they will be expensive for some users.

[$] The importance of being noisy

Post Syndicated from corbet original https://lwn.net/Articles/762510/rss

Hundreds (at least) of kernel bugs are fixed every month. Given the
kernel’s privileged position within the system, a relatively large portion
of those bugs have security implications. Many bugs are relatively easily
noticed once they are triggered; that leads to them being fixed. Some
bugs, though, can be hard to detect, a result that can be worsened by the
design of in-kernel APIs. A proposed change to how user-space accessors
work will, hopefully, help to shine a light on one class of stealthy bugs.

The 4.18 kernel is out

Post Syndicated from corbet original https://lwn.net/Articles/762429/rss

Linus has released the 4.18 kernel.
It was a very calm week, and arguably I could just have released on
schedule last week, but we did have some minor updates.

Some of the significant features in this release include
unprivileged filesystem mounts,
restartable sequences,
a new zero-copy TCP receive API,
support for active state management for
power domains,
the AF_XDP mechanism for
high-performance networking,
the core bpfilter packet filter
implementation,
and more. See the KernelNewbies 4.18 page for
more details.

[$] The mismatched mount mess

Post Syndicated from corbet original https://lwn.net/Articles/762355/rss

“Mounting” a filesystem is the act of making it available somewhere in the
system’s directory hierarchy. But a mount operation doesn’t just glue a
device full of files into a specific spot in the tree; there is a whole set
of parameters controlling how that filesystem is accessed that can be
specified at mount time. The handling of these mount parameters is the
latest obstacle to getting the proposed new
mounting API
into the mainline; should the new API reproduce what is
arguably one of the biggest misfeatures of the current mount()
system call?

bzip.org changes hands

Post Syndicated from corbet original https://lwn.net/Articles/762264/rss

The bzip2 compression algorithm has been slowly falling out of
favor, but is still used heavily across the net. A search
for “bzip2 source”
returns bzip.org as the first three results. But it
would seem that the owner of this domain as let it go, and it is now parked
and running ads. So we no longer have an official home for
bzip2. If a new repository or tarball does turn up at that
domain, it should be looked at closely before being trusted. (Thanks to
Jason Kushmaul).

[$] Scheduler utilization clamping

Post Syndicated from corbet original https://lwn.net/Articles/762043/rss

Once upon a time, the only way to control how the kernel’s CPU scheduler
treated any
given process was to adjust that process’s priority. Priorities are no
longer enough to fully control CPU scheduling, though, especially when
power-management concerns are taken into account. The utilization
clamping patch set
from Patrick Bellasi is the latest in a series of
attempts to allow user space to tell the scheduler more about any specific
process’s needs.

[$] WireGuarding the mainline

Post Syndicated from corbet original https://lwn.net/Articles/761939/rss

The WireGuard VPN tunnel has been
under development — and attracting attention — for a few years now; LWN ran a review of it in March. While WireGuard
can be found in a number of distribution repositories, it is not yet
shipped with the mainline kernel because its author, Jason Donenfeld, hasn’t
gotten around to proposing it for upstreaming. That changed on on
July 31, when Donenfeld posted
WireGuard
for review
. Getting WireGuard itself into the mainline would probably
not be
all that hard; merging some of the support code it depends on could be
another story, though.

[$] Testing web applications with Selenium

Post Syndicated from corbet original https://lwn.net/Articles/761629/rss

Whenever one is engaged in large-scale changes to a software project, it is
nice to have some assurance that regressions are not being introduced in
the process. Test suites can be helpful in that regard. But while the
testing of low-level components can be relatively straightforward, testing
at the user-interface level can be harder. Web applications, which must
also interact with web browsers, can be especially challenging in this
regard. While working on just this sort of
project
, your editor finally got around to looking at Selenium
WebDriver
as a potential source of help for the testing problem.

[$] The Grumpy Editor’s Python 3 experience

Post Syndicated from corbet original https://lwn.net/Articles/761328/rss

LWN has been running articles for years to the effect that the end of
Python 2 is nigh and that code should be ported to Python 3
immediately. So,
naturally, one might expect that our own site code, written in Python, had been
forward-ported long ago. Strangely enough, that didn’t actually happen.
It has mostly happened now, though. In the process of doing this
work, your editor has noticed a few things that don’t necessarily appear in
the numerous porting guides circulating on the net.

[$] A quick history of early-boot memory allocators

Post Syndicated from corbet original https://lwn.net/Articles/761215/rss

One might think that memory allocation during system startup should not be
difficult: almost all of memory is free, there is no concurrency,
and there are no background tasks that will compete for memory. Even so,
boot-time memory management is a tricky task. Physical memory is not
necessarily contiguous, its extents change from system to system, and
the detection of those extents may be not trivial. With NUMA things
are even more complex because, in order to satisfy allocation
locality, the exact memory topology must be determined.
To cope with this, sophisticated mechanisms for memory management are
required even
during the earliest stages of the boot process.

Read on for a history of the evolution of the kernel’s early-boot memory
allocator, contributed by Mike Rapoport.