The Rust for Linux project, sponsored by Google, has advanced with use of a beta Rust compiler (as opposed to a nightly build), testing ARM and RISC-V architecture support, new Rust abstractions, and more.
A new set of patches submitted to the Linux kernel mailing list summarises the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.
Project leader Miguel Ojeda is a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux. In his post, he begun by explaining that infallible allocations have been removed via a customised “alloc” standard library crate. An infallible allocation is where the developer assumes that an allocation of memory will always succeed. If it does not succeed, Rust terminates the process. Infallible allocations are not acceptable in the kernel since failures cause a kernel panic. A fallible allocation lets the developer test for success.
“Eventually, the goal is to have everything the kernel needs in upstream ‘alloc’ and drop it from the kernel tree,” he said.
Rust for Linux requires new features in the Rust compiler (rustc) as well as in the kernel code. Therefore, the project has been using nightly releases of rustc. This is no longer necessary as the beta of rustc 1.54 is sufficient. When rustc 1.54 is fully released, it will be the reference compiler for the project.
Writing unit tests for Rust kernel code now works with the standard Rust #test attribute. They do not yet run in kernel, but “the goal is to have them run in kernel space, so that we can test code that depends on kernel features,” Ojeda wrote.
ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports.
There is a proposal to merge this work into the main Rust codebase, which raises a licensing issue because Rust uses MIT and Apache v2 whereas GCC uses GPLv3. The Rust Foundation reviewed the issue and concluded that “the proposed change will not impact the license of rustc except when it is built with the gcc backend, in which case GPLv3 will apply to the resulting binary” – meaning the compiler binary, not the applications it compiles.
The patches also include new Rust abstractions for Kernel C objects such as “red-black trees, reference-counted objects, file descriptor creation, tasks, files, io vectors,” said Ojeda.
Overall, “the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules,” he continued.
There is substantial support for the project across the industry. Google said in April “we feel that Rust is now ready to join C as a practical language for implementing the kernel” and that it would reduce the number of potential bugs and security vulnerabilities.
Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of “efforts to move the internet’s critical software infrastructure to memory safe code,” under the project name Prosimio. The ISRG is also the nonprofit organisation behind Let’s Encrypt free security certificates.
Ojeda also mentioned that Microsoft’s Linux Systems Group is contributing and hopes to submit “select Hyper-V drivers written in Rust.” Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.
More detail is promised at the forthcoming Linux Plumber’s Conference in September. In the meantime, the project is on GitHub here.
Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is “getting to the point where maybe it might be mergeable for 5.14 or something like that.”
In the latest patches, Ojeda proposed to use big-endian order for long symbols in the kernel symbol table, needed because Rust symbols “can become quite long due to namespacing introduced by modules, types, traits, generics.” Torvalds responded: “Why is this in big-endian order? Let’s just try to kill big-endian data, it’s disgusting and should just die already… networking has legacy reasons from the bad old days when byte order wars were still a thing, but those days are gone.”
If that easily fixed detail is his main objection then so far, so good. ®