Kernel Picks: Collabora and LWN
-
Collabora ☛ Smart audio filters with WirePlumber 0.5
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically insert themselves in between client streams and devices.
-
LWN ☛ Improving control-flow integrity for Linux on RISC-V
Redirecting execution flow is a common malware technique that can be used to compromise operating systems. To protect from such attacks, the chip makers of leading architectures like x86 and arm64 have implemented control-flow-integrity (CFI) extensions, though they need system software support to function. At the Linux Security Summit North America, RISC-V kernel developer Deepak Gupta described the CFI protections for that architecture and invited community input on the kernel support for them.
RISC-V is an instruction set architecture (ISA) that follows the philosophy of open-source hardware. Its attractiveness lies in its lack of ISA licensing fees and that it is extensible, allowing designers to integrate custom instructions and features tailored to their specific needs. Notably, startups have chosen to adopt RISC-V and the European Union has made substantial investment toward developing its own chips based on the architecture.
-
LWN ☛ Capturing stack traces asynchronously with BPF
Andrii Nakryiko led a session at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit giving a look into the APIs for capturing stack traces using BPF, and how the APIs could be made more useful. BPF programs can capture the current stack trace of a running process, including the portion in the kernel during execution of a system call, which can be useful for diagnosing performance problems, among other things. But there are substantial problems with the existing API.
The existing way to get stack traces in BPF is to create a BPF map for containing the elements of the trace, and then to call bpf_get_stackid() from the BPF side, which returns a unique ID for the map, Nakryiko explained. Then in user space, the program could do a normal map lookup to retrieve the stack trace. The kernel also captures and stores some related information, such as the ELF build ID and the file offset, which helps identify what program the stack trace corresponds to for offline analysis. This API sounds fairly simple, but unfortunately it has a few quirks, he said.
-
LWN ☛ BPF tracing performance
On the final day of the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit, the BPF track opened with a series of sessions on improving the performance and flexibility of probes and other performance-monitoring tools, in the kernel and in user space. Jiri Olsa led two sessions about different aspects of probes: making the API for BPF programs attached to a probe more flexible, and making user-space probes more efficient.
Olsa introduced an improvement to kprobes; he posted a new way to attach a single program to the entry and exit hooks for a function. This is already technically possible, but it's a pain to work with, because the BPF program has no way to match entries and exits up with one another. Olsa's new API, called kprobe_multi, will give the BPF program a cookie to match calls to the entry and exit hooks with each other, as well as allowing the entry hook to request that the exit hook be skipped if the event is not something the BPF program is interested in.
-
LWN ☛ Static keys for BPF
The kernel has a lot of code paths that are normally disabled: debugging print statements, tracepoints, etc. To support these efficiently, there is a common mechanism called static keys that provides a way to enable or disable a code path at run time, with effectively no overhead for disabled branches. BPF programs have not been able to take advantage of static keys so far, because they aren't compiled into the kernel. Now, it looks like BPF may be getting support for a similar mechanism — and the design could also provide one of the components needed to support jump tables, another missing feature. Anton Protopopov presented his plans to add static keys to BPF at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit.
-
LWN ☛ Simplifying the BPF verifier
The BPF verifier is a complex program. This has the unfortunate effect of making it simultaneously more difficult for contributors to work on, and more likely to harbor unknown bugs. Shung-Hsi Yu had two concrete proposals for how to simplify the verifier to make it easier to maintain that he presented at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit. Yu proposed changing how the verifier tracks partially known values and cleaning up the interface to hide the details of the value-tracker's internal representation.
-
LWN ☛ Nested bottom-half locking for realtime kernels
Software-interrupt handlers (also called "bottom halves") have a long history in the Linux kernel; for much of that history, developers have wished that they could go away. One of their unfortunate characteristics is that they can add unexpected latency to the execution of unrelated processes; this problem is felt especially acutely in the realtime-preemption community. The solution adopted there has created problems of its own, though; in response Sebastian Andrzej Siewior is proposing a new locking mechanism for realtime builds of the kernel that may have benefits for non-realtime users as well.
In normal kernel builds, a software-interrupt handler will run, if needed, at the earliest opportunity that the kernel finds; usually, that is immediately after the completion of a hardware-interrupt handler or on return from the kernel to user space. Either way, software-interrupt handling can delay the execution of a process that may have nothing to do with the creation of that interrupt. For most systems, that delay is not usually a problem, but realtime kernels are all about response time; a badly timed software-interrupt handler has the potential to cause a realtime task to miss its deadline.
It turns out that the realtime developers are firmly of the opinion that they have not worked on that project for over two decades just to be thwarted by a software-interrupt handler. So those handlers have been made preemptible like nearly everything else in realtime kernels. That change only addresses part of the problem, though. The kernel makes heavy use of per-CPU variables as a way of avoiding contention between processors; as long as no other CPU can access a memory location, there will be no contention for it, and no need for locking to ensure mutual exclusion. Except, of course, if a software-interrupt handler runs and tries to access the same data.