All posts by corbet

[$] Relief for retpoline pain

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

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.

[$] Linux in mixed-criticality systems

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

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 may be removed

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

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.

Hutterer: Understanding HID report descriptors

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

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.

[$] A filesystem corruption bug breaks loose

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

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.

[$] Kernel quality control, or the lack thereof

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

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.

[$] Toward race-free process signaling

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

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’s Edge browser moving to Chromium

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

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.”

[$] Bounded loops in BPF programs

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

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
.

Kernel prepatch 4.20-rc5

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

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.

[$] Binary portability for BPF programs

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

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.