> Android Binder Driver: This project is an effort to rewrite Android's Binder kernel driver in Rust.
> Motivation: Binder is one of the most security and performance critical components of Android. Android isolates apps from each other and the system by assigning each app a unique user ID (UID). This is called "application sandboxing", and is a fundamental tenet of the Android Platform Security Model.
> The majority of inter-process communication (IPC) on Android goes through Binder. Thus, memory unsafety vulnerabilities are especially critical when they happen in the Binder driver
> [...] We also need designs that allow code in the two languages to interact with each other: we're particularly interested in safe, zero-cost abstractions that allow Rust code to use kernel functionality written in C, and how to implement functionality in idiomatic Rust that can be called seamlessly from the C portions of the kernel.
> Since Rust is a new language for the kernel, we also have the opportunity to enforce best practices in terms of documentation and uniformity. For example, we have specific machine-checked requirements around the usage of unsafe code: for every unsafe function, the developer must document the requirements that need to be satisfied by callers to ensure that its usage is safe; additionally, for every call to unsafe functions (or usage of unsafe constructs like dereferencing a raw pointer), the developer must document the justification for why it is safe to do so.
> We'll now show how such a driver would be implemented in Rust, contrasting it with a C implementation. [...]
There aren't really any non-trivial mainline modules, since the Rust support is so new. There's the non-mainline Asahi M1 GPU driver though! It will eventually be mainlined, but IIRC some more Rust support code needs to be mainlined first.
On Android the Linux kernel is its own thing, and after Project Treble, it follows a microkernel like approach to drivers, where standard Linux drivers are considered "legacy" since Android 8.
In your opinion, do you think that the microkernel approach is more secure? (Should processes run as separate users with separate SELinux contexts like Android 4.4+)
Why do you think that the Android binder module rust implementation is listed as an example of a Rust for Linux kernel module on the site?
> The Android open-source project "AOSP" with its latest code is very close to being able to boot off the mainline Linux kernel when assuming the device drivers are all upstream.
Of course microkernel approach is more secure, if a driver gets p0wned, corrupts data structures, or plain keeps crashing, it doesn't take the whole kernel with it.
Naturally the issue might be as bad that the whole stack can't recover from, but still much better than corrupting the kernel.
One of the SecDevOps guidelines when hardening servers is that every process should have its own user, yes.
Kmods and akmods run in kernel memory space and aren't ABI stable.
I fear "Project Treble" may reduce incentives for vendors to upstream their drivers. Are there efforts to mainline it or the drivers currently using it?
Followed by GSI (Generic System Images), where AOSP can be plugged alongside modular component packages, thus allowing OEMs a more Lego like experience to creating custom Android builds
Binder is not a HAL, since binder is how HALs communicate with each other. It's an actual proper Linux driver. The C version is in the upstream kernel as a module you can enable when building the kernel.
IIRC, when I tried to install LEGO Boost app (before I found pybricks and wokwi simulator) on Waydroid, I had trouble patching Bluetooth BLE on the host through to the waydroid container; due to device virtualization less than modules fwiu
https://rust-for-linux.com/ links to LWN articles at https://lwn.net/Kernel/Index/#Development_tools-Rust that suggest that only basic modules are yet possible with the rust support in Linux kernels 6.2 and 6.3.
Rust-for-linux links to the Android binder module though: https://rust-for-linux.com/Android-Binder-Driver.html :
> Android Binder Driver: This project is an effort to rewrite Android's Binder kernel driver in Rust.
> Motivation: Binder is one of the most security and performance critical components of Android. Android isolates apps from each other and the system by assigning each app a unique user ID (UID). This is called "application sandboxing", and is a fundamental tenet of the Android Platform Security Model.
> The majority of inter-process communication (IPC) on Android goes through Binder. Thus, memory unsafety vulnerabilities are especially critical when they happen in the Binder driver
... "Rust in the Linux kernel" (2021) https://security.googleblog.com/2021/04/rust-in-linux-kernel... :
> [...] We also need designs that allow code in the two languages to interact with each other: we're particularly interested in safe, zero-cost abstractions that allow Rust code to use kernel functionality written in C, and how to implement functionality in idiomatic Rust that can be called seamlessly from the C portions of the kernel.
> Since Rust is a new language for the kernel, we also have the opportunity to enforce best practices in terms of documentation and uniformity. For example, we have specific machine-checked requirements around the usage of unsafe code: for every unsafe function, the developer must document the requirements that need to be satisfied by callers to ensure that its usage is safe; additionally, for every call to unsafe functions (or usage of unsafe constructs like dereferencing a raw pointer), the developer must document the justification for why it is safe to do so.
> We'll now show how such a driver would be implemented in Rust, contrasting it with a C implementation. [...]
Is this the source for the rust port of the Android binder kernel module?: https://android.googlesource.com/platform/frameworks/native/...
This guide with unsafe rust that calls into the C, and then with next gen much safer rust right next to it would be a helpful resource too.
What of the post-docker container support (with userspaces also written in go) should be cloned to rust first?
What are some good examples of non-trivial Linux kernel modules written in Rust?