Kernel watch
Jon Masters summarises the latest happenings in the Linux kernel, so that you don’t have to.
“There are many other motivations behind Rust, which appears similar in some respects to C++, with a few hints of Pascal and Python thrown in”
Tinus Torvalds announced the release of Linux 5.12-rc7, noting that it was likely there would be (relatively rare) RC8 (Release Candidate 8) this time around due to the large number of patches that went in at the last minute, in particular to address a few networking concerns. All of which means that the next merge window (period of time during which disruptive changes can land), and all of the goodies that brings, is likely to be in time for next issue.
Meanwhile tremendous advancement in support for Apple “M1” Macs being able to run Linux natively. This bare metal support has come at a ridiculously fast pace, likely motivated by the performance of the Apple Silicon, which has caused a strong interest in running Linux on it. Linux 5.13 should contain initial support, and we’ll break it down (and run the code) in next month’s issue.
Rust support on Linux
In recent times, one can’t go anywhere on the internet without hearing about the joys of programming in Rust (don’t tell Reddit–ed).
The thing with traditional “systems” programming languages like C (and to an extent, C++) is that they don’t come with memory safety built-in. You can do “unsafe” and dangerous things in C during the course of normal use.
A “systems” programming language is one that enables you to get pretty close to the metal. In traditional terms, it’s a language that allows a programmer to write an Operating System in it because it provides sufficient abstractions while also allowing sufficient expressiveness to control the hardware. C is famous for its extensive use of pointers and direct memory allocation routines that require a skilful understanding of how memory works, while simultaneously providing no safety net against simple typos or trivial bugs that leak memory (or worse). According to various research, the vast majority of security bugs we see today can be traced to some unfortunate unsafe memory usage bug.
The classical example of this is a buffer overflow in which a region of memory is allocated by a program but is later convinced to write more data into that region than the size allocated (hence the “overflow”). The overwritten data typically spills over into some other program code or data, replacing it with attacker controlled data that alters the program’s operation, typically to gain privilege escalation (and thus “root” on the machine). Since programs are only getting more complex, strong motivation exists for a different alternative to using traditional C-like languages.
Enter Rust.
In Rust, fundamental concepts such as “ownership” mean that data is always owned by a single entity at a time. References to that data can be passed around (“borrowed”), but a compile-time “borrow checker” will ensure that this happens in a safe manner. There are many other motivations behind Rust, which appears similar in some respects to C++, with a few hints of Pascal and Python thrown in for good measure. While the language is not (yet) a formal standard, it already has a cult following.
Among the followers are many developers associated with large projects such as Android, which is seeking to leverage Rust more in new projects. At the same time, strong interest exists in whether Rust could be used to author certain components within the Linux kernel, such as new device drivers. To that end, a first gathering on the topic was held at Linux Plumbers Conference 2020, where the upshot was that Miguel Ojeda organised the effort into the “Rust for Linux” project (github). Fast forward to today and as we go to press, the first patches implementing Rust support for Linux have been posted to the Linux Kernel Mailing List (LKML).
It’s early days for Rust in Linux, and will likely take years to get merged, but Linus has already said “on the whole I don’t hate it”. High praise.