{"id":146042,"date":"2025-10-21T23:12:38","date_gmt":"2025-10-21T21:12:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-yadro-linux-6-18-prinyata-realizacziya-binder-ipc-dlya-android-napisannaya-na-rust"},"modified":"2025-10-21T23:12:38","modified_gmt":"2025-10-21T21:12:38","slug":"v-yadro-linux-6-18-prinyata-realizacziya-binder-ipc-dlya-android-napisannaya-na-rust","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-yadro-linux-6-18-prinyata-realizacziya-binder-ipc-dlya-android-napisannaya-na-rust","title":{"rendered":"The implementation of Binder IPC for Android, written in Rust, has been accepted into the Linux kernel 6.18.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The codebase of the Linux kernel, on which version 6.18 is based, has accepted the implementation of the inter-process communication mechanism Binder, written in Rust. Binder is used in Android to organize interaction between processes and remote method calls (one Android process can invoke a method or function in another Android process, using Binder to identify, call, and pass arguments between processes). The Binder code was rewritten in Rust as part of a project aimed at enhancing security, promoting safe programming practices, and improving the efficiency of memory issue detection in Android (about 70% of all critical vulnerabilities identified in Android are caused by memory handling errors). <\/p>\n
Using Rust has solved several issues that Binder developers faced, including errors related to reference counting, deadlocks, and boundary checks, while significantly reducing error handling complexity. The Binder implementation in Rust is functionally similar to the original version in C, passes all AOSP (Android Open-Source Project) tests, and can be used to create working versions of Android firmware. Despite its advanced features and support for objects with complex ownership semantics, the Rust driver is smaller than the C version \u2014 5.5 versus 5.8 thousand lines of code. <\/p>\n
In the commit description, the author mentions the following motivations for rewriting Binder: <\/p>\n
\n
Binder has been evolving for 15 years, and during that time, its functionality and complexity have significantly increased \u2014 the project is at the intersection of all Android components and covers many tasks beyond IPC:\n
\n
correct analysis and transformation of transaction contents that may contain multiple objects of different types (e.g., pointers, file descriptors) interacting with each other;\n
controlling thread pool sizes in user space and ensuring the assignment of transactions to threads in such a way as to avoid deadlocks when the thread pool is exhausted;\n
tracking reference counters of objects shared by multiple processes, correctly forwarding changes to reference counters between processes;\n
processing numerous error scenarios while coordinating 13 different locks, 7 link counters, and atomic variables. In doing so, it must perform such tasks as quickly and accurately as possible. <\/ul>\n
The old codebase has accumulated significant technical debt, complicating both bug detection and further development. For instance, large functions exceeding a thousand lines of code, questionable error handling methods, and convoluted structures are found in the core.\n
Binder is a critical security component of Android, as platform elements operating in isolated sandbox environments, such as the rendering process in Chrome and the SW Codec, have direct access to it. A vulnerability in Binder would allow bypassing isolation. The high complexity combined with technical debt significantly complicates maintaining a high level of security in Binder. <\/ul>\n