Linux: 6.1, WireGuard, and Rust
-
The search for the correct amount of split-lock misery [LWN.net]
Unlike many other architectures, x86 systems support atomic operations that affect more than one cache line. This support comes at a cost, though, in terms of overall system performance and, even, security. Over the last few years, kernel developers have worked to discourage the use of this sort of "split-lock" operation. Now, though, one group of users is feeling a little too discouraged, leading to a discussion of how much misery can appropriately be inflicted upon users who use problematic but architecturally legal operations.
The problem with atomic operations that cross cache-line boundaries is that the system bus must take special measures to ensure that both cache lines are simultaneously protected from concurrent access. In practice, that means locking the bus for the duration of the operation, which can stall every other processor in the system. A malicious program executing a tight loop with a split-lock operation can destroy the performance of the system as a whole. For this reason, split-lock operations have long been frowned upon.
Unfortunately, software that is malicious (or just poorly written) turns out to be remarkably indifferent to even the most severe of frowns. So, starting in 2019, kernel developers sought more persuasive ways to get their point across. The initial work was done by Fenghua Yu but, in the end, this patch by Peter Zijlstra was merged in January 2020 for the 5.7 kernel release.
-
The rest of the 6.1 merge window
Linus Torvalds released 6.1-rc1 and closed the 6.1 merge window on October 16; at that point, 11,537 non-merge changesets had been pulled into the mainline repository. That is considerably less than the 13,543 changesets pulled during the 6.0 merge window, but quantity is not everything: there were quite a few significant changes brought in this time around. Many of those were part of the nearly 5,800 changesets pulled since our first 6.1 merge window summary; read on for a look at some of the work done in the latter part of this merge window.
-
Identity management for WireGuard
Since its inclusion in the Linux kernel, the WireGuard VPN tunnel has become increasingly popular. In general, WireGuard is simpler to configure than other VPNs, but the approach that it takes to authentication can present some challenges. Each node in a WireGuard network has a cryptographic key that serves as the node's identity; nodes that do not know each other's keys cannot directly communicate. Keeping track of these keys and distributing them to the other nodes in a mesh network quickly becomes a chore as the network grows. Fortunately, there are now several open-source tools that can automate the management of these keys and make using WireGuard easier for both administrators and end users.
Key management can be particularly challenging for non-technical end users, who are used to logging into services with a username and password. Thus, the main feature that all of these tools have in common is that they allow a user to log into a WireGuard network using a username and password (and possibly a second factor, such as a one-time password). This is usually accomplished by integrating with an identity provider that implements the OpenID Connect (OIDC) standard. OIDC is built on top of the OAuth 2.0 protocol and can be used to implement the ubiquitous "Sign in with Some Big Company" functionality seen on many web sites.
Some of the software discussed in this article requires an OIDC provider; there are several open-source options for people who aren't already running their own and don't want to farm the task out to some big company. Keycloak is one of the most mature and popular choices and Authelia is an up-and-coming alternative.
-
A first look at Rust in the 6.1 kernel [LWN.net]
October 13, 2022 There have been a lot of significant changes merged into the mainline for the 6.1 release, but one of the changes that has received the most attention will also have the least short-term effect for users of the kernel: the introduction of support for the Rust programming language. No system with a production 6.1 kernel will be running any Rust code, but this change does give kernel developers a chance to play with the language in the kernel context and get a sense for how Rust development feels. Perhaps the most likely conclusion for most developers, though, will be that there isn't yet enough Rust in the kernel to do much of anything interesting.
Work on Rust for the Linux kernel has been going on for a few years, and it has resulted in the creation of a lot of support code and some interesting drivers to look at. There are other initiatives underway, including the writing of an Apple graphics driver in the Rust language. For the initial merge into the mainline kernel, though, Linus Torvalds made it clear that as little functionality as possible should be included. So those drivers and their support code were trimmed out and must wait for a future kernel release. What is there is the support needed to build a module that can be loaded into the kernel, along with a small sample module.