LWN Articles About Linux Kernel and Graphics
-
Nolibc: a minimal C-library replacement shipped with the kernel [LWN.net]
The kernel project does not host much user-space code in its repository, but there are exceptions. One of those, currently found in the tools/include/nolibc directory, has only been present since the 5.1 release. The nolibc project aims to provide minimal C-library emulation for small, low-level workloads. Read on for an overview of nolibc, its history, and future direction written by its principal contributor.
The nolibc component actually made a discreet entry into the 5.0 kernel as part of the RCU torture-test suite ("rcutorture"), via commit 66b6f755ad45 ("rcutorture: Import a copy of nolibc"). This happened after Paul McKenney asked: "Does anyone do kernel-only deployments, for example, setting up an embedded device having a Linux kernel and absolutely no userspace whatsoever?"
-
Hiding a process's executable from itself [LWN.net]
Back in 2019, a high-profile container vulnerability led to the adoption of some complex workarounds and a frenzy of patching. The immediate problem was fixed, but the incident was severe enough that security-conscious developers have continued to look for ways to prevent similar vulnerabilities in the future. This patch set from Giuseppe Scrivano takes a rather simpler approach to the problem.
The 2019 incident, which came to be known as CVE-2019-5736, involved a sequence of steps that culminated in the overwriting of the runc container-runtime binary from within a container. That binary should not have even been visible within the container, much less writable, but such obstacles look like challenges to a determined attacker. In this case, the attack was able to gain access to this binary via /proc/self/exe, which always refers to the binary executable for the current process.
Specifically, the attack opens the runc process's /proc/self/exe file, creating a read-only file descriptor — inside the container — for the target binary, which lives outside that container. Once runc exits, the attacker is able to reopen that file descriptor for write access; that descriptor can subsequently be used to overwrite the runc binary. Since runc is run with privilege outside of the container runtime, this becomes a compromise of the host as a whole; see the above-linked article for details.
This vulnerability was closed by having runc copy its binary image into a memfd area and sealing it; control is then be passed to that image before entering the container. Sealing prevents modifying the image, but even if that protection fails, the container is running from an independent copy of the binary that will never be used again, so overwriting it is no longer useful. It is a bit of an elaborate workaround, but it plugged the hole at the time.
-
Kernel code on the chopping block [LWN.net]
Code that is added to the kernel can stay there for a long time; there is code in current kernels that has been present for over 30 years. Nothing is forever, though. The kernel development community is currently discussing the removal of two architectures and one filesystem, all of which seem to have mostly fallen out of use. But, as we will see, removal of code from the kernel is not easy and is subject to reconsideration even after it happens.
-
X clients and byte swapping [LWN.net]
While there are still systems with both byte orders, little-endian has largely "won" the battle at this point since the vast majority of today's systems store data with the least-significant byte first (at the lowest address). But when the X11 protocol was developed in the 1980s, there were lots of systems of each byte order, so the X protocol allowed either order and the server (display side) would swap the bytes to its byte order as needed. Over time, the code for swapping data in the messages, which was written in a more-trusting era, has bit-rotted so that it is now a largely untested attack surface that is nearly always unused. Peter Hutterer has been doing some work to stop using that code by default, both in upstream X.org code and in downstream Fedora.
A Fedora 38 change proposal to disable support for byte-swapped clients by default in the X server was posted in mid-December. It is owned by Hutterer, who proposed adopting the work he was doing for the X.org server into Fedora. At the time, it was unclear whether the upstream changes would land in time, so the Fedora proposal was contingent on that happening. It turns out that Hutterer merged the changes on January 5, so that would not be an impediment to Fedora being an early adopter of the feature.