Shulou(Shulou.com)06/02 Report--

This article focuses on "how to use Rust for Linux kernel development", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to use Rust for Linux kernel development.

For a long time, one of the goals of the Rust programming language has been to replace the C language most commonly used in the development of the operating system kernel. As Rust matures, many developers are more and more interested in trying Rust in the Linux kernel. At the 2020 (virtual) Linux Plumbers Conference meeting, among the many topics of the LLVM micro-meeting, there was a discussion about the unresolved issues or obstacles to accepting Rust code in the Linux kernel. This is the most attended meeting in 2020, which shows how interested people are in this topic.

Many developers have done a lot of work before this conference, including a presentation by Alex Gaynor and Geoffrey Thomas at the Linux Security Summit Security Summit last year. At that time, they introduced a prototype of the Rust kernel module and made a case for using Rust in the kernel. Their focus is on security issues, pointing out that about 2/3 of kernel vulnerabilities in Android and Ubuntu are allocated to CVE, all of which come from memory security issues. In principle, Rust can completely avoid such errors with the more secure API provided by its type system and borrow checker.

Since then, Linus Torvalds and other kernel maintainers have expressed an open mind in principle to kernel development that supports Rust, so the Plumbers meeting aims to outline specific requirements that will allow Rust to enter Linux kernel. This meeting was proposed and discussed on the linux-kernel mailing list, and some of the topics for discussion were already put forward at that time.

The conference also featured Thomas and Gaynor, as well as the co-leader of the Josh Triplett--Rust language team, a long-time developer of the Linux kernel-and other interested developers. They talked briefly about their work so far, as well as some of their initial ideas and problems, and then spent most of their time discussing it. They give a simple example of what kernel-mode Rust code might look like (from Thomas and Gaynor's linux-kernel-module-rust project, https://github.com/fishinabarrel/linux-kernel-module-rust/).

Speakers stressed that they were not proposing to rewrite the Linux kernel into Rust, they were just focused on moving towards a world where new code could be written in Rust. The next conversation focuses on three potential concerns supported by Rust: leveraging existing API in the kernel, architectural support, and issues related to ABI compatibility between Rust and C.

Binding to an existing C API (Binding to existing C APIs)

If Rust is to be of practical value to kernel development, it is not enough for Rust to be able to generate code that can be linked to the kernel. It also needs a way for Rust to access a large number of API used in the Linux kernel, which are currently defined in C header files. Rust has good support for interoperability with C code, including functions that can be called using C ABI and functions that define C-compatible ABI, which can be called in the C language. In addition, the bindgen tool can parse the C header file and generate the corresponding Rust declaration, so that Rust does not have to repeat the definition from C, which also provides a degree of cross-language type checking.

On the face of it, these features give Rust the ability to integrate with the existing C API, but the devil is in the details, and the work so far and the conversation at the meeting show that there are many challenges in the implementation. For example, Linux makes extensive use of preprocessing macros (preprocessor macro) and inline functions (inline function), which are not easily supported by the foreign-function interface interfaces of bindgen and Rust.

For example, the very common kmalloc () function is defined as _ _ always_inline, which means that all its calls are inline, and without the kmalloc () symbol in the kernel symbol table, Rust cannot make linked calls. This problem can be easily solved by defining a kmalloc_for_rust () symbol that contains a non-inline version, but manually handling these workarounds can lead to a lot of manual work and repetitive code. It is possible to do this automatically with an improved version of bindgen, but this is not currently available in the tool.

The conversation also raised the second question about API binding: how much manual "wrapped" does C API need to provide an authentic Rust interface? If you look at the two existing Rust kernel module projects, you can see some of the troubles here.

In linux-kernel-module-rust projects, pointers to user space are wrap to UserSlicePtr, which ensures that copy_to_user () or copy_from_user () can be used correctly. This wrapper provides a degree of security in the Rust code (because such pointers cannot be directly dereference) and also makes the Rust code more authentic. To write a user-space pointer, the code looks like this:

User_buf.write & kernel_buffer?

The "?" here. Is part of the Rust error handling mechanism, a style of return and handling error handling that is ubiquitous in Rust. This type of wrapper makes existing Rust developers more familiar with the resulting Rust and makes Rust's type system and borrow checker as secure as possible. However, every API needs such careful design and development, and the workload is huge, which will lead to different API of the modules written by C and Rust.

John Baublitz's demo module (https://github.com/jbaublitz/knock-out) is a user access function that is directly bound to the kernel. The corresponding code looks like this:

If kernel::copy_to_user (buf, & kernel_ buffer [0.count])! = 0 {

Return-kernel::EFAULT

}

This modification is easy to implement, binding is mainly automatically generated by bindgen, and for existing kernel developers, they will be less resistant to review or modify Rust code. However, for Rust developers, this kind of code is less accustomed to and may lose some of the security that Rust could have guaranteed.

It was agreed at the meeting that it was necessary to write a Rust version of wrapper for some of the most common key API, but it was not possible to write a wrapper for every kernel API manually, which was not desirable. Thomas mentioned that Google is studying the canonical binding action to automatically generate C++ code, and wonder if the kernel can do something similar, perhaps based on the existing sparse annotation (the semantic checking tool used in kernel), or by adding some new comments to the existing C code to guide binding generator's work.

Architecture support (Architecture support)

The next topic of discussion is architectural support. At present, the only mature Rust compiler is rustc, which generates script through LLVM. The Linux kernel supports many architectures, some of which do not have an off-the-shelf LLVM back-end (backend). Some other architectures have a LLVM backend, but rustc does not yet support it. The speaker wondered whether full-architecture support was an obstacle to enabling Rust in the kernel.

Several people say that implementing drivers in Rust is acceptable, but in any case, these drivers will never be used on relatively rare architectures. Taking his experience in the Debian project as an example, Triplett believes that adding Rust to the kernel will help drive more architectural support for Rust. He mentioned that introducing Rust software into Debian will help inspire fans and users of niche architectures to increase their support for Rust, and he believes that adding Rust to the kernel will have a similar effect. In particular, any architecture with a LLVM back end is expected to be supported by rustc soon.

Other optional versions of Rust implementations are also mentioned in the conversation, which can help support more architectures. The mrustc project is an experimental Rust compiler that generates C code. Using mrustc, it is possible for Rust to be compiled by the C compiler used to compile the rest of the kernel.

In addition, Triplett mentions some work on the Rust front end (front end) for GCC, which has the potential to enable Rust to support any architecture supported by GCC. The project is still in its early stages, but it also provides another way to make up for architectural support gaps in the future. Although the conclusions of this section do not give a very definite answer, it seems that no one is strongly opposed to the plan to "support Rust device drivers first and then complete more architectural support".

Compatibility of ABI with kernel (ABI compatibility with the kernel)

Gaynor also asks you about the compatibility of ABI. Because Rust (currently) is compiled through LLVM, and the kernel is built in GCC, linking Rust code to the kernel may mean mixing GCC and LLVM-generated code. Although LLVM's goal is to be compatible with GCC's ABI, there is still some concern that this approach will create a small risk of ABI incompatibility, so there is some resistance. The speakers wondered whether the kernel community would prefer to limit Rust support to kernels built with Clang to ensure compatibility.

Greg Kroah-Hartman confirms that the current kernel rule is that compatibility is guaranteed only if all object files (object file) in the kernel are built using the same compiler and using the same flags. However, he also said that the Rust object built by LLVM can be linked to the kernel built by GCC, as long as the objects are built at the same time, the appropriate options are set, and the resulting set of configuration is fully tested. He believes that there is no need for additional restrictions before practical problems arise. Florian Weimer clarified that ABI problems are often not obvious in the corner of the language. For example, this is the case where a structure containing bitfield is returned by returning a value. He believes that the most important and commonly used parts of ABI should not cause compatibility problems.

Triplett stressed that calls between GCC and Rust are common and normal usage in user space, so in terms of Rust, he is not worried about compatibility. It sounds like this problem should not be an obstacle to introducing Rust into the kernel in the end.

Conclusion (Conclusions)

No specific next steps were decided at the end of the meeting, but overall, there was a growing consensus on the enthusiasm and need for eventual support for Rust module. The next important step is likely to be for someone to propose a real Rust driver and incorporate it into the kernel. As long as there is a specific use case and implementation, always push hard to figure out any remaining controversial issues and reach design conclusions.

At this point, I believe you have a deeper understanding of "how to use Rust for Linux kernel development". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.