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.
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.
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.
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.”
“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?
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).
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.
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.
Version
60 of the Thunderbird email client has been released. “This
version of Thunderbird is packed full of great new features, fixes, and
changes that improve the user experience and make for a worthwhile
upgrade.” There are improvements in calendar management and the
handling of attachments, among other things; see the
release notes for details.
Richard Hughes announces
that the Linux Vendor Firmware Service
will start distributing firmware updates for Lenovo systems.
“Obviously, this is a big deal. Tens of thousands of people are
likely to be offered a firmware update in the next few weeks, and hundreds
of thousands over the next few months.”
As expected, Linus has released 4.18-rc8
rather than the final 4.18 release. “So as already mentioned a
couple of times in some of the relevant threads, this last week wasn’t
entirely painless, and 4.18 ended up being one of those releases that gets
an extra week of rc testing before release“.
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.
Version 2.28 of the GNU C Library is out. Changes include support for
Intel’s “Control-flow Enforcement Technology”, Unicode 11.0.0 support, a
wrapper for statx(), ISO C
threads support, several security fixes, and more.
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.
For those waiting on the edges of their seats for the release of the 4.18
kernel: it looks like Linus will be pushing it back one week (to
August 12) in response to some late-discovered problems. “I _prefer_ just
the regular cadence of releases, but when I have a
reason to delay, I’ll delay.”
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.
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.