Indirect function calls — calls to a function whose address is stored in a
pointer variable — have never been blindingly fast, but the Spectre
hardware vulnerabilities have made things far worse. The indirect branch
predictor used to speed up indirect calls in the CPU can no longer be
used, and performance has suffered accordingly. The “retpoline”
mechanism
was a brilliant hack that proved faster than the hardware-based solutions
that were tried at the beginning. While retpolines took a lot of the pain
out of Spectre mitigation, experience over the last year has made it clear
that they still hurt. It is thus not surprising that developers have been
looking for alternatives to retpolines; several of them have shown up on
the kernel lists recently.
The Linux kernel is generally seen as a poor fit for safety-critical
systems; it was never designed to provide realtime response guarantees or
to be certifiable for such uses. But the systems that can be used
in such settings lack the features needed to support complex applications.
This problem is often solved by deploying a mix of computers running
different operating systems. But what if you want to support a mixture of
tasks, some safety-critical and some not, on the same system? At a talk
given at LinuxLab 2018, Claudio
Scordino described an effort to support this type of mixed-criticality
system.
The x32 subarchitecture
is a software variant of x86-64; it runs the processor in the 64-bit mode,
but uses 32-bit pointers and arithmetic. The idea is to get the advantages
of x86-64 without the extra memory usage that goes along with it. It
seems, though, that x32 is not much appreciated; few distributions support
it and the number of users appears to be small. So now Andy Lutomirski is proposing
its eventual removal:
I propose that we make CONFIG_X86_X32 depend on BROKEN for a release
or two and then remove all the code if no one complains. If anyone
wants to re-add it, IMO they’re welcome to do so, but they need to do
it in a way that is maintainable.
If there are x32 users out there, now would be a good time for them to
speak up.
Git 2.20.0 is out. Changes include interdiff generation support in git
format-patch, an improved ability to cope with corrupted patches in git am, a number of performance and usability improvements, and more.
Version
15 of the Nextcloud productivity and communications platform is out.
New features include Mastodon integration, two-factor authentication, a
number of user-interface improvements, and more.
For those who would like a deeper understanding of how the human interface
device (HID) protocol works, Peter Hutterer has posted a
detailed overview. “Originally HID was designed to work over
USB. But just like Shrek the technology world is obsessed with layers so
these days HID works over different transport layers. HID over USB is what
your mouse uses, HID over i2c may be what your touchpad uses. HID works
over Bluetooth and it’s celebrity-diet version BLE. Somewhere, someone out
there is very slowly moving a mouse pointer by sending HID over carrier
pigeons just to prove a point. Because there’s always that one guy.”
Kernel bugs can have all kinds of unfortunate consequences, from
inconvenient crashes to nasty security vulnerabilities. Some of the most
feared bugs, though, are those that corrupt data in filesystems. The
losses imposed on users can be severe, and the resulting problems may not
be noticed for a long time, making recovery difficult. Filesystem
developers, knowing that they will have to face their users in the real
world, go to considerable effort to prevent this kind of bug from finding
its way into a released kernel. A recent failure in that regard raises a
number of interesting questions about how kernel development is done.
The 4.20-rc6 kernel prepatch is out for
testing.
“Most of it looks pretty small and normal. Would I have preferred for
there to be less churn? Yes. But it’s certainly smaller than rc5 was,
so we’re moving in the right direction, and we have at least one more
rc to go.”
Filesystem developers tend toward a high level of conservatism when it
comes to making changes; given the consequences of mistakes, this seems
like a healthy survival trait. One might rightly be tempted to regard a
recent disagreement over the backporting of filesystem-related fixes to the
stable kernels as an example of this conservatism, but there is more to
it. The kernel development process has matured in many ways over the
years; perhaps this discussion hints at some of the changes that will be
needed to continue that maturation in the future.
Signals have existed in Unix systems for years, despite the general
consensus that they are an example of a bad
design. Extensions and new ways of using signals pop up from time to
time, fixing the issues that have been found. A notable addition was the
introduction of signalfd()
nearly 10 years ago. Recently, the kernel developers have discussed how to avoid
race conditions related to process-ID (PID) recycling, which occurs when a
process
terminates and another one is assigned the same PID. A process that fails
to notice that its target has exited may try to send a signal to the wrong
recipient, with potentially grave consequences. A patch set from Christian
Brauner is trying to solve the issue by adding
signaling via file descriptors.
Microsoft has announced
that its “Edge” browser is joining the Chromium world. “Today we’re announcing that we intend to adopt the Chromium open source project in the development of Microsoft Edge on the desktop to create better web compatibility for our customers and less fragmentation of the web for all web developers.
As part of this, we intend to become a significant contributor to the Chromium project, in a way that can make not just Microsoft Edge — but other browsers as well — better on both PCs and other devices.”
Videos from the 2018 Linux Plumbers Conference (November 13-15, Vancouver)
have now been posted for all sessions, including the Kernel Summit and
Networking tracks. They can be found by going to the
detailed schedule and clicking on the session of interest.
The BPF verifier is charged with ensuring that any given BPF program is
safe for the kernel to load and run. Programs that fail to terminate are
clearly unsafe, as they present an opportunity for denial-of-service
attacks. In current kernels, the verifier uses a heavy-handed technique to
block such
programs: it disallows any program containing loops. This works, but at the
cost of disallowing a wide range of useful programs; if the verifier could
determine whether any given loop would terminate within a bounded time,
this restriction could be lifted. John Fastabend presented a plan for
doing so during the BPF
microconference at the 2018 Linux Plumbers
Conference.
The 4.20-rc5 kernel prepatch is out; among
other things, it contains the STIBP changes described in this article. Linus is also thinking about
release timing: “So my current suggestion is that we plan on a
Christmas release, everybody gets their pull requests for the next merge
window done *before* the holidays, and then we see what happens. I think we
all want to have a calm holiday season without either the stress of a merge
window _or_ the stress of prepping for one.”
The BPF virtual machine is the same on all architectures where it is
supported; architecture-specific code takes care of translating BPF to
something the local processor can understand. So one might be tempted to
think that BPF programs would be portable across architectures but, in many
cases, that turns out not to be true. During the BPF microconference at the Linux Plumbers
Conference, Alexei Starovoitov (assisted by Yonghong Song, who has done
much of the work described) explained
the problem and the work that has
been done toward “compile once, run everywhere” BPF.
The Software Freedom Conservancy reports
that the first hearing in the appeal of the GPL
enforcement lawsuit against VMware has been held in Germany.
“The hearing yesterday was a tiny step in a long process toward
resolving this issue, and, as we understand the situation, nothing is yet
decided.”
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.