news
Latest From LWN, Microsoft Azure Falls Offline Again
-
GNU/Linux
-
Kernel Space
-
LWN ☛ BPF signing LSM hook change rejected
BPF lets users load programs into a running kernel. Even though BPF programs are checked by the verifier to ensure that they stay inside certain limits, some users would still like to ensure that only approved BPF programs are loaded. KP Singh's patches adding that capability to the kernel were accepted in version 6.18, but not everyone is satisfied with his implementation. Blaise Boscaccy, who has been working to get a version of BPF code signing with better auditability into the kernel for some time, posted a patch set on top of Singh's changes that alters the loading process to not invoke security module hooks until the entire loading process is complete. The discussion on the patch set is the continuation of a long-running disagreement over the interface for signed BPF programs.
One might hope that signing BPF programs would just be a matter of attaching a signature to the program, and then checking that signature. Alas, things are a bit more complicated. BPF uses "compile once — run everywhere" (CO-RE) relocations to let compiled programs run on multiple different kernel versions. Thus, the version of the BPF program on disk is not exactly the same as the version presented to the kernel for loading, which invalidates any signatures on the BPF binary.
Singh's patch set solves this problem by using a two-step process: first, user space loads a specialized BPF program, called a loader, that does not require relocations (and so can have its signature checked directly by the kernel). Then, the loader program verifies that the real program matches a hash stored in the loader. That hash covers the code of the real program (as well as some BPF maps containing configuration), so a correctly implemented loader won't load a program that has been tampered with. This design has the benefit of presenting a relatively minimal user-space interface, but moving part of the program-verification process out of the kernel proper and into BPF code is a potential downside.
-
-
-
Distributions and Operating Systems
-
Mobile Systems/Mobile Applications
-
LWN ☛ Retrieving pixels from Android phones with Pixnapping
A new class of attacks on Android phones, called "Pixnapping", was announced on October 13. It allows a malicious app to gather output rendered in a victim app, pixel-by-pixel, by exploiting a GPU side-channel. Depending on what the victim app displays, anything from sensitive email and chats to two-factor authentication (2FA) codes could be captured—and shipped off to an attacker's site.
As noted in the Pixnapping paper (with seven authors from various universities), pixel-stealing attacks are not new. They were described in 2013 in the context of web browsers, using iframes and SVG filters; since then, browsers have largely mitigated those kinds of attacks with various restrictions. Pixnapping applies the ideas behind pixel stealing to Android's apps, completely outside of the browser context—though the browser is also an app so it can also be targeted. The demo video on the Pixnapping site shows a malicious app relaying 2FA credentials from the Google Authenticator app in less than the 30-second timeout, which allowed the "attacker" to log into a Reddit account.
The vulnerability uses Android intents to cause a specific app to start, thus to send its output into the rendering pipeline, but it does so with flags that cause the victim app's output not to appear on the phone screen. A stack of semi-transparent Android activities are added on top of the output via the malicious app sending more intents. All of that can be done without the user realizing any of it has happened, even if the intended victim app is not installed—normally sending an intent to a nonexistent app gives a warning to the user, but that can be bypassed by catching an exception in the malicious app.
-
-
-
Free, Libre, and Open Source Software
-
Funding
-
LWN ☛ GoFundMe to delete unwanted open-source foundation pages
Historically, the GoFundMe platform has been used to allow individuals or groups to crowdfund for specific events, rather than as a tool for nonprofits' official fundraising efforts. For example, a couple might put up a page to raise funds for a honeymoon, or a family might use it to pool money to celebrate grandma's 80th birthday. The site is, sad to say, now commonly used to attempt to raise funds for medical bills or groceries rather than for happy occasions. No doubt many LWN readers have been invited to contribute to something on GoFundMe since the platform was launched.
Apparently, though, the company decided to branch out beyond medical debt and try to persuade its users to use the platform to funnel all charitable donations through the site. However, for that scheme to work, users have to be able to donate to charities through GoFundMe. Rather than waiting for nonprofits to join the platform voluntarily, though, the company seems to have decided it will simply start taking donations on behalf of the those organizations without consulting them first.
A recent story from ABC 7 News in California reported that GoFundMe had created pages for 1.4 million 501(c)(3) organizations using US Internal Revenue Service (IRS) public data. That includes many open-source nonprofits, such as the PSF, which currently has a page on the platform that sports a "verified" badge. It does not say what has been verified, but it is definitely not the PSF's approval of the page. Deb Nicholson, executive director of the PSF, said in an email that the foundation was aware of the page.
-
-
Programming/Development
-
LWN ☛ Fil-C: A memory-safe C implementation
Fil-C is a memory-safe implementation of C and C++ that aims to let C code — complete with pointer arithmetic, unions, and other features that are often cited as a problem for memory-safe languages — run safely, unmodified. Its dedication to being ""fanatically compatible"" makes it an attractive choice for retrofitting memory-safety into existing applications. Despite the project's relative youth and single active contributor, Fil-C is capable of compiling an entire memory-safe Linux user space (based on Linux From Scratch), albeit with some modifications to the more complex programs. It also features memory-safe signal handling and a concurrent garbage collector.
Fil-C is a fork of Clang; it's available under an Apache v2.0 license with LLVM exceptions for the runtime. Changes from the upstream compiler are occasionally merged in, with Fil-C currently being based on version 20.1.8 from July 2025. The project is a personal passion of Filip Pizlo, who has previously worked on the runtimes of a number of managed languages, including Java and JavaScript. When he first began the project, he was not sure that it was even possible. The initial implementation was prohibitively slow to run, since it needed to insert a lot of different safety checks. This has given Fil-C a reputation for slowness. Since the initial implementation proved viable, however, Pizlo has managed to optimize a number of common cases, making Fil-C-generated code only a few times slower than Clang-generated code, although the exact slowdown depends heavily on the structure of the benchmarked program.
Reliable benchmarking is notoriously finicky, but in order to get some rough feel for whether that level of performance impact would be problematic, I compiled Bash version 5.2.32 with Fil-C and tried using it as my shell. Bash is nearly a best case for Fil-C, because it spends more time running external programs than running its own code, but I still expected the performance difference to be noticeable. It wasn't. So, at least for some programs, the performance overhead of Fil-C does not seem to be a problem in practice.
-
-
-
Leftovers
-
Proprietary
-
Security
-
LWN ☛ Safer speculation-free user-space access
The Spectre class of hardware vulnerabilities truly is a gift that keeps on giving. New variants are still being discovered in current CPUs nearly eight years after the disclosure of this problem, and developers are still working to minimize the performance costs that come from defending against it. The masked user-space access mechanism is a case in point: it reduces the cost of defending against some speculative attacks, but it brought some challenges of its own that are only now being addressed.
The Spectre vulnerabilities can be used to exfiltrate data from the kernel in a number of ways, but the attacks usually come down to exercising a kernel path that will speculatively execute with an attacker-provided address, leaving traces of the target data that can then be recovered via a side channel. One of the most common ways to defeat such attacks is to simply prevent speculative execution of some code; it is effective, but also expensive.
-
-