Google Rewriting Android's Binder In Rust With Promising Results

[phoronix]

Phoronix: Google Rewriting Android's Binder In Rust With Promising Results

Google engineers on Wednesday posted an initial "request for comments" set of patches that re-implement Android's Binder code within the Linux kernel in the Rust programming language rather than C...

https://www.phoronix.com/news/Google-Linux-Binder-In-Rust

[Sethox]

And another Rust rewrite project. In all serious though, if it gain benefits then try it. Google has enough money to spend on such investments.

[bug77]

Poor sobs, they didn't ask kpedersen, he would have warned them they're heading towards doom abandoning C. Oh well...

[bug77]

And another Rust rewrite project. In all serious though, if it gain benefits then try it. Google has enough money to spend on such investments.

What some fail to realize is that while it is possible to write memory/thread safe code in C, Rust makes it dead-simple do to so. It increases developer productivity. That's why it has so many success stories behind it.
(And yes, it's not fit for everything, I know that. Doesn't mean it's not fit for anything.)

[timofonic]

Why Android requires a custom IPC mechanism instead using or providing a standardized in in the Linux kernel ecosystem that may be used for the rest?

Android project says the standard Linux IPC mechanisms (pipes, sockets, shared memory) are not suitable for Android's performance, security, and power efficiency requirements. I don't get it.

Why is Binder better than the rest? They say the following:

It reduces the number of copies between processes, using scatter-gather optimization and direct memory mapping.
It supports fine-grained locking and real-time priority inheritance, which improves concurrency and responsiveness.
It provides a transparent proxy mechanism that allows clients to invoke methods on remote objects as if they were local.
It enforces security policies based on Linux user IDs and SELinux contexts, which prevents unauthorized access to system services and resources.
It supports reference counting and death notifications, which helps manage the lifecycle of remote objects and handle failures gracefully.

How is it used? It seems Binder is used by various components of the Android system, such as:

- The application framework and the system services, which communicate through AIDL interfaces and Intents.
- The hardware abstraction layer (HAL) and the vendor services, which communicate through HIDL interfaces and vndbinder.
- The native daemons and the system server, which communicate through NDK binder APIs and libbinder.

If Linux IPC is lacking, I don't see why Google can't be good Linux kernel citizens and integrate their innovative ways into standard Linux mechanisms.


I see most reaons are historical ones:
- Binder was originally developed by Be Inc. for their BeOS operating system in the 1990s, long before Android was created. Google acquired the rights to use binder when they bought some of Be’s assets in 2005. Therefore, binder is not a Google invention, but a legacy technology that they adopted for Android.
- Binder is not compatible with the Linux kernel’s design principles, such as simplicity, modularity, and portability. Binder introduces a complex and monolithic IPC framework that requires significant changes to the kernel codebase and affects other subsystems.
- Binder is not widely used or supported by other Linux-based systems or platforms. Binder is specific to Android and its use cases, and there is little demand or incentive for other Linux developers or vendors to adopt or maintain it.


Binder is an old and non-standard IPC mechanism that clashes with the Linux kernel's design and goals. It complicates the kernel, isolates Android from other Linux systems, and exposes the kernel to user-space bugs and attacks. Binder should be replaced by a new IPC mechanism that uses standard Linux features, such as cgroups, namespaces, seccomp, and epoll. Improve them to reach the same feature and performance at least. This would make the kernel simpler, faster, safer, and more collaborative.

[Kjell]

At least in a Binder throughput benchmark the Rust version is +/- 2% of the C version.

Faster or slower?

[dlq84]

Faster or slower?

It says +/-.

[kpedersen]

Doesn't mean it's not fit for anything.)

It does mean that people are going to waste a whole lot of time on something that ultimately will not work out.

Oh well...

Oh well indeed. Luckily I am not reliant on their tech so am more than happy to watch from the sidelines at this unfold.

[Volta]

Android project says the standard Linux IPC mechanisms (pipes, sockets, shared memory) are not suitable for Android's performance, security, and power efficiency requirements. I don't get it.

Android's security and performance in single sentence sounds like a joke. Binder makes it even more comical:

https://www.infosecurity-magazine.com/news/binder-flaw-blows-apart-android

Binder is the means by which all apps talk to the underlying system layer. It was created thus to reduce the attack surface, however, given it occupies such an important role itself, Binder has become a prime target for Android malware, they argue.

“Subverting this component allows an attacker to see and control almost all important data being transferred within the system,” the two say in their research paper.

Effectively, if an attacker is able to control any link in the chain which leads all the way from Java APIs at one end to the native Binder code at the other they can launch a “Man in the Binder” attack.

But what to expect from clown company like google?

[wagaf]

Binder is an old and non-standard IPC mechanism that clashes with the Linux kernel's design and goals. It complicates the kernel, isolates Android from other Linux systems, and exposes the kernel to user-space bugs and attacks. Binder should be replaced by a new IPC mechanism that uses standard Linux features, such as cgroups, namespaces, seccomp, and epoll. Improve them to reach the same feature and performance at least. This would make the kernel simpler, faster, safer, and more collaborative.

Using these IPC mechanisms as a developer, you quickly realize how clean and well designed Binder is compared to using stuff like shared memory or to other mechanism like DBUS.

Using shared memory for IPC instead of Binder is like using mutexes and locks and threads instead of a clean event-loop with async/await.
More complexity, more code, more bugs and less performance.

The path forward should be to merge Binder in the Linux kernel. The value for users should always be the ultimate goal of a software (or any product) and Binder provides value that other IPC mechanisms in Linux don't.