All posts by corbet

[$] Android memory management

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

The Android system is designed to provide a responsive user experience on
systems that, in a relative sense at least, have limited amounts of
CPU and memory. Doing so requires a number of techniques, including
regular use of
a low-memory process killer, that are not seen elsewhere. In a
memory-management-track session at the 2019 Linux Storage, Filesystem, and
Memory-Management Summit, Suren Baghdasaryan covered a number of issues
related to how Android ensures that interactive processes have enough
memory to get their jobs done.

[$] Memory encryption issues

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

“People think that memory encryption sounds really cool; it will make my
system more secure so I want it”. At least, that is how Dave Hansen
characterized the situation at the beginning of a session on the topic
during the memory-management track at the 2019 Linux Storage, Filesystem,
and Memory-Management Summit. This session, also led by Kirill Shutemov,
covered a number of aspects of the memory-encryption problem on Intel
processors and beyond. One clear outcome of the discussion was also raised
by Hansen at the beginning: users of memory encryption need to think hard
about where that extra security is actually coming from.

[$] Toward a reverse splice()

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

The splice()
system call is, at its core, a write operation; it attempts to implement
zero-copy I/O by moving pages from a pipe to a file. At the 2019 Linux
Storage, Filesystem, and Memory-Management Summit, Miklos Szeredi described
a nascent idea for rsplice() — a “reverse splice” system call.
There were not a lot of definitive outcomes from this discussion, but one
thing was clear: rsplice() needs a much better description (and
some code posted) before the development community can begin to form an
opinion on it.

[$] The state of system observability with BPF

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

The 2019 version of the Linux Storage, Filesystem, and Memory-Management
Summit opened with a plenary talk by Brendan Gregg on observing the state
of Linux systems using BPF. It is, he said, an exciting time; the
BPF-based “superpowers” being added to the kernel are growing in capability and
maturity. It is now possible to ask many questions about what is happening
in a production Linux system without the need for kernel modifications or
even basic debugging information.

[$] Bounce buffers for untrusted devices

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

The recently discovered vulnerability in
Thunderbolt
has restarted discussions about protecting the kernel
against untrusted, hotpluggable hardware. That vulnerability, known as Thunderclap, allows a hostile external
device to exploit Input-Output
Memory Management Unit (IOMMU)
mapping limitations and access system
memory it was not intended to. Thunderclap can be exploited by
USB-C-connected devices; while we have seen USB attacks in the past, this
vulnerability is different in that PCI devices, often considered as
trusted, can be a source of attacks too. One way of stopping those attacks
would be to make sure that the IOMMU is used correctly and restricts the device
to accessing the memory that was allocated for it. Lu Baolu has posted
an implementation of that approach
in the form of bounce buffers for
untrusted devices.

[$] SGX: when 20 patch versions aren’t enough

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

Intel’s “Software Guard
Extensions
” (SGX) feature allows the creation of
encrypted “enclaves” that cannot be accessed from the rest of the system.
Normal code can call into an enclave, but only code running inside the
enclave itself can access the data stored there. SGX is pitched as a way
of protecting data from a hostile kernel; for example, an encryption key
stored in an
enclave should be secure even if the system as a whole is compromised.
Support for SGX has been under development for over three years; LWN covered it in 2016. But, as can be seen from
the response to the
latest revision of the SGX patch set
, all that work has still not
answered an important question: what protects the kernel against a hostile
enclave?

A year with Spectre: a V8 perspective

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

Here’s an article on the V8 blog
describing the work that was done to mitigate Spectre vulnerabilities in
the V8 JavaScript engine. “Our research reached the conclusion that,
in principle, untrusted code can read a process’s entire address space
using Spectre and side channels. Software mitigations reduce the
effectiveness of many potential gadgets, but are not efficient or
comprehensive. The only effective mitigation is to move sensitive data out
of the process’s address space.

The end of Scientific Linux

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

Fermilab has maintained Scientific Linux, a derivative of Red Hat
Enterprise Linux, for many years. That era is coming to an end, though:
Toward that end, we will deploy CentOS 8 in our scientific computing
environments rather than develop Scientific Linux 8. We will collaborate
with CERN and other labs to help make CentOS an even better platform for
high-energy physics computing.
” Maintenance of the SL6 and SL7
distributions will continue as scheduled.

[$] Implementing fully immutable files

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

Like all Unix-like systems, Linux implements the traditional protection
bits controlling who can access files in a filesystem (and what access
they have). Fewer users, perhaps, are aware of a set of additional
permission bits hidden away behind the chattr
and lsattr
commands. Among other things, these bits can make a file append-only,
mark a file to be excluded from backups, cause a file’s data to be automatically
overwritten on deletion, or make a file immutable. The implementation of
many of these features is incomplete at best, so perhaps it’s not
surprising that immutable files can still be changed in certain
limited circumstances. Darrick Wong has posted a
patch set
changing this behavior, implementing a user-visible
behavioral change that he describes as “an extraordinary way to
destroy everything
“.

[$] Tracking pages from get_user_pages()

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

As has been recently discussed here,
developers for the filesystem and memory-management subsystems have been
grappling for years with the problems posed by the get_user_pages()
mechanism. This function maps memory into the kernel’s address space for
direct access by the kernel or peripheral devices, but that kind of access
can create confusion in the filesystem layers, which may not be expecting
that memory to be written to at any given time. A new patch
set
from Jérôme Glisse tries to chip away at a piece of the problem,
but a complete solution is not yet in view.

[$] Avoiding page reference-count overflows

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

The 5.1-rc5 announcement mentioned
changes all over” and highlighted a number of the areas that
had been touched. One thing that was not mentioned there was the
addition of four patches fixing a security-related issue in the core
memory-management subsystem. The vulnerability is sufficiently difficult
to exploit that almost nobody should feel the need to rush out a kernel
update, but it is still interesting to look at as a demonstration of how
things can go wrong.