Release of Rust 1.81. Hurdles in promoting Rust to the Linux kernel

The release of the general-purpose programming language Rust 1.81 has been published, originally based on the Mozilla project, but now developed under the auspices of the independent nonprofit organization Rust Foundation. The language focuses on safe memory management and provides means for achieving high parallelism in task execution, all without the need for a garbage collector and runtime (the runtime is limited to basic initialization and support of the standard library).

The memory management methods in Rust relieve developers from errors when manipulating pointers and protect against issues arising from low-level memory operations, such as accessing memory after it has been freed, dereferencing null pointers, buffer overflows, and so on. For distributing libraries, ensuring builds, and managing project dependencies, the package manager Cargo is being developed. A repository at crates.io supports library hosting.

Safe memory handling in Rust is ensured at compile time through reference checking, ownership tracking of objects, lifetime consideration (scope) of objects, and assessment of memory access correctness during code execution. Rust also provides means to protect against integer overflows, mandates the initialization of variable values before use, improved error handling in the standard library, employs the concept of immutability for references and variables by default, and offers strong static typing to minimize logical errors.

Key innovations:

• The core::error::Error trait has been stabilized, defining the descriptions of errors that are output. This change allows for the use of a single Error trait across various libraries, regardless of the environment, including libraries not tied to the standard library that use the attribute "#![no_std]".
• Stable and unstable sorting functions in the standard library have been transitioned to use new algorithms that demonstrate higher performance and reduced compilation time. The implementation of the new sorting algorithms ensures the identification of incorrectly defined Ord traits and outputs errors (panic) in such cases instead of randomly grouped data.
• A new lint check level called "expect" ("#[expect(lint)]") has been implemented in the linter, allowing verification of checks and producing a warning if the check is not passed (due to an implementation error or check being disabled). For instance, when migrating a codebase to use the undocumented_unsafe_blocks check through Clippy, one can specify "#[expect(clippy::undocumented_unsafe_blocks)]" to ensure that all unsafe blocks are documented during the transition. Clippy also includes checks for clippy::allow_attributes and clippy::allow_attributes_without_reason, simplifying the replacement of the "#[allow]" attributes with "#[expect(lint)]".
• The ability to document the reason for changing lint levels has been provided, giving new developers information about the reasons for adding specific checks, which is output as a compiler message. For example: #![deny(clippy::float_arithmetic, reason = "no hardware float support")]
• A new batch of APIs has been promoted to stable, including stabilized methods and trait implementations:
  • core::error
  • hint::assert_unchecked
  • fs::exists
  • AtomicBool::fetch_not
  • Duration::abs_diff
  • IoSlice::advance
  • IoSlice::advance_slices
  • IoSliceMut::advance
  • IoSliceMut::advance_slices
  • PanicHookInfo
  • PanicInfo::message
  • PanicMessage

  The 'const' keyword, defining the ability to be used in any context instead of constants, is applied in functions:

  • char::from_u32_unchecked (function)
  • char::from_u32_unchecked (method)
  • CStr::count_bytes
  • CStr::from_ptr

  The type std::panic::PanicInfo has been renamed to std::panic::PanicHookInfo (the old name will continue to work, but starting from the next version, its use will trigger a warning). Meanwhile, core::panic::PanicInfo will remain unchanged but will evolve as a separate type. This separation will allow different methods specific to execution contexts of snd and no_std to be implemented within them.

• The transition to ABI C-unwind ('extern "C-unwind"'), which differs from the ABI without the '-unwind' suffix ('extern "C"'), has been completed. It maintains safe behavior if the unwinding process, initiated during a program crash or exceptions in C++ style, crosses the ABI boundary (for example, when an exception occurring in code of one programming language affects the stack related to code in another language during unwinding). Starting with Rust 1.81, the 'extern "C"' ABI involves unwinding on uncaught exceptions.
• Third-level support has been implemented for platforms i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. The third level implies basic support but without automated testing, official build releases, or build verification.
• Second-level support for target platforms loongarch64-unknown-linux-musl and arm64ec-pc-windows-msvc has been implemented. Second level support guarantees successful builds.
• Full tooling and profiling support has been provided for Linux systems on the LoongArch platform.
• A vulnerability (CVE-2024-43402) in std::process::Command has been fixed, which only appears on the Windows platform, addressing a workaround for the previously patched BatBadBut vulnerability related to the handling of special characters in Command::arg and Command::args, which are designed for direct argument passing to processes without being processed by the command interpreter. In practice, when running bat and cmd scripts, the cmd.exe process was invoked, which has its own logic for argument separation. The bypass was based on Windows removing leading spaces and dots in paths, meaning a file with the extension '.bat. .' was processed as '.bat'.

Additionally, it is worth noting the departure of Wedson Almeida Filho from the position of maintainer of the Rust for Linux project, which implements Rust development tools in the Linux kernel. After Wedson's departure, the project is left with two maintainers—Miguel Ojeda, the author and main developer of the Rust-for-Linux project, and Alex Gaynor, a former director of the Python Software Foundation, who has shifted focus to promoting Rust. The departing maintainer, who joined the project four years ago, is an employee of Microsoft and the author of an experimental driver implementing the EXT2 filesystem, written in Rust. Recently, Almeida's work has centered on creating tools for developing filesystems in Rust. This year Almeida has contributed 17 commits to the Rust-for-Linux repository (in comparison, Miguel Ojeda contributed 53 commits).

The reason for Almeida's departure is cited as a lack of energy and enthusiasm that once existed for responding to some nontechnical nonsense. According to Almeida, developers are forced to expend excessive effort on disputes over trivial issues that undermine a more significant global goal. Almeida continues to believe that the future of kernels lies in the use of languages that ensure safe memory handling, and if the Linux developer community does not recognize this, Linux will be replaced by another kernel, as Unix was in its time.

Supporters of the Rust-for-Linux project face the challenge of overcoming resistance from established kernel developers who see no need to learn a new language. In his resignation letter, Almeida references a discussion that took place during his and Kent Overstreet's presentation at the "Linux Storage, Filesystem, Memory-Management, and BPF Summit," which was dedicated to using Rust for filesystem development. Ted Ts’o, the author of the ext2/ext3/ext4 filesystems, criticized the initiative, comparing Rust-for-Linux to an attempt to force everyone to adopt the Rust religion.

In response to Almeida's intention to create a wrapper over the C-written filesystem interfaces for their use in Rust code, Ted Ts’o pointed out that such a wrapper would inevitably lead to problems, since any changes to the C interfaces and refactoring would require modifying the Rust wrapper, and he does not want to take on the extra responsibility of fixing issues in Rust code and tracking the status of the Rust wrapper. C code is constantly evolving, and if its changes disrupt the Rust wrapper, it will also affect all filesystems dependent on that wrapper.

Ted also believes that in the foreseeable future, the wrapper for Rust will remain secondary, and any issues with the bindings will only be a headache for Rust-for-Linux developers, not for the community of filesystem developers in the kernel. It's noted that not all developers are going to learn Rust, so after making changes that affect other code, they can only update the dependent C code, but will not be able to fix Rust wrappers since they do not know Rust. James Bottomley, who maintains the SCSI subsystem, also joined the discussion, stating that the more semantics that are encoded in the wrappers, the more brittle they become in terms of ensuring synchronization.

Meanwhile, Google, which rewrote the pvmfm firmware used in virtual machines, running on the Android platform, shared insights on the gradual integration of Rust code into existing firmware originally written in C or C++. It demonstrated how to significantly enhance the security of firmware by creating functionally identical replacement components written in Rust. Special attention is recommended when implementing Rust to focus on using it for new code and code that performs functions critical to security (e.g., code that processes external data received from untrusted sources). For integrating Rust and C code, it is suggested to use shim layers that translate calls between Rust and C APIs (C API exported for use in Rust code and vice versa), allowing for a phased rewrite of API elements in Rust.

Source: opennet.ru