9 ms·
The Binder Linux driver is being rewritten in Rust
- leononame 3y agoReally unexpected, that the first kernel feature written in Rust is such a huge driver, I would've expected something much smaller first. The reasoning for the change is well laid out imo. I'm looking forward to this, especially since it looks like performance will be almost on par with the C version which will give Rust a good outlook.
- imjonse 3y agoIt is a very good candidate I think. Vendor specific, does not affect anything non-Android, Google is on it.
- mgaunard 3y agoIs it really "huge"? Seems like a pretty well isolated subsystem with a fairly narrow feature set to me. They say 6,000 lines of code. That's not very much.
- syntheweave 3y agoIt's surprising by importance but not by size, which is actually a sweet spot for evaluating a new systems language - a small dependency that everything uses.
- mgaunard 3y agoIt's just an Android thing which could arguably be entirely in userspace.
- jeroenhd 3y agoThat's something that comes up more often, because many feel this shouldn't be in the kernel in the first place. The problem is that there hasn't been a proper userspace alternative with similar performance characteristics. I think putting this stuff in the kernel is rather silly, but I'd rather have it in the kernel than bring back the rift between Android and Linux.
- HankB99 3y agoDoes the isolation between processes in Android require that it be in the kernel or can some other form of privilege bridge the separation?
- mgaunard 3y ago"similar performance characteristics"? I can exchange data at a quarter of the latency using normal shared memory.
- jeroenhd 3y agoI'm not sure how you'd port binder's security guarantees to simple shared memory. Binder is more than just IPC, it also provides an RPC mechanism as well as some isolation capabilities.
- mgaunard 3y agoI'm sure it does more things that make it useful, and that it provides a practical programming model for certain platforms, but it's certainly not the lowest latency way to do inter-process communication.
- pjmlp 3y agoGiven the microkernel-like approach taken by Project Treble, at least some part of it needs to live on the kernel for fast message interchange.
- agent327 3y agoThe only thing that needs to live in the kernel is fast message interchange. And that could also be used as the base mechanism to move all(!) of the drivers out of the kernel.
- speed_spread 3y agoI was just mulling this over yesterday with the story about USB tablet driver regression. Running drivers as user processes would essentially give the kernel a stable ABI. But then we'd see a proliferation of closed-source drivers - there wouldn't be motivation to upstream hardware support anymore. Is that a hidden goal behind this fast IPC thingy?
- pjmlp 3y agoSince Android 8 that the only in-kernel drivers are what the Android team considers legacy drivers, aka standard Linux kernel drivers pre-Project Treble. Hence why modern Android drivers are called Binderized drivers. https://source.android.com/docs/core/architecture/hal https://source.android.com/docs/core/architecture/hal
- aaronmdjones 3y agoIt isn't the first feature, but it may well end up being the first one that makes it into mainline. https://lpc.events/event/16/contributions/1180/attachments/1017/1961/deck.pdf https://lpc.events/event/16/contributions/1180/attachments/1...
- mgaunard 3y agoFor those, like me, who have never heard of what it is, Binder is an IPC mechanism for Android.
- yu3zhou4 3y agoAnd IPC stands for interprocess communication > the mechanisms provided by an operating system for processes to manage shared data https://en.wikipedia.org/wiki/Inter-process_communication https://en.wikipedia.org/wiki/Inter-process_communication
- monocasa 3y agoAnd before that Palm, and before that Be. https://en.wikipedia.org/wiki/OpenBinder https://en.wikipedia.org/wiki/OpenBinder
- goodthenandnow 3y agoAlso, as mentioned in the patch's message, it's important to highlight that binder is a core component of Android. Its usage is so widespread that, to me, it kinda makes Android architecture very akin to a microkernel-based system.
- sillywalk 3y agoHere's some more background (from 2006 ) "OpenBinder is the core technology that ex-Be engineers started at Be, Inc. as the “next generation BeOS”, finished implementing at PalmSource " https://www.osnews.com/story/13674/introduction-to-openbinder-and-interview-with-dianne-hackborn/ https://www.osnews.com/story/13674/introduction-to-openbinde...
- pixelesque 3y agoDoes Rust prevent all mistakes with locking as the post seems to indicate? It prevents the most common issues of accessing variables without mutexes or something incorrectly by requiring them to be wrapped in RwLock or similar, but you can still get deadlocks can you not?
- sapiogram 3y agoRust does not protect against deadlocks, that is correct. It also doesn't fully prevent mistakes related to ref counting. But I don't get the impression that the post is claiming either of those things?
- pixelesque 3y agoWell, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :) I'd argue that "It prevents mistakes with ref counting, locking, bounds checking..." implies "all" mistakes, but hey, maybe not...
- nextaccountic 3y agoRust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex https://github.com/dragazo/rustex
- masklinn 3y agoYeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code. The main missing piece in rust locks is inter-lock dependencies when they are not nested.
- thesuperbigfrog 3y ago>> Rust-style locks definitely raise the bar, and I wish more languages adopted this This locking pattern is quite old and frequently available in safe languages. Ada calls it "protected objects" and has had it since Ada 95: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html#protected-objects https://learn.adacore.com/courses/intro-to-ada/chapters/task... Java calls it "synchronized" and has had it since Java 5 or 6: https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html https://docs.oracle.com/javase/tutorial/essential/concurrenc...
- alex_suzuki 3y agoI remember working with Binder in the context of Android/AIDL (IPC between apps). Wonder if Dianne Hackborn is still involved, she‘s notably absent in TFA. Her name was synonymous with Binder back then.
- pjmlp 3y agoNowadays it also does IPC between kernel and drivers, not only apps.
- nercury 3y agoFor anyone unfamiliar how rust helps, the idea is this: first, you can identify common usage patterns and build safe wrappers around raw system operations. The wrappers have no additional cost when compiled: A nested structure of Wrapper<OtherWrapper<OverSomePointer>> has a size of the flattened contained data, all the type info will be stripped away. This part is the hardest, but the reward is that you can then use these wrappers without thinking about lower-level details. Of course, it is possible to do that in other languages, but rust type system can encode more information in types. That means more checks at compile time and less cautionary instructions are needed in the code comments. I always hear arguments that "Rust still does not prevent X!". That's not the point. Rust type system simply can prevent more if used as intended.
- Ygg2 3y ago> I always hear arguments that "Rust still does not prevent X!". That's not the point. Rust type system simply can prevent more if used as intended. That's just the Nirvana fallacy. Just because it's not perfect shouldn't prevent you from improving stasus quo. Absurd example: "Seatbelts don't prevent impalements or drowning in car, ergo they are useless.
- stefs 3y agothe seatbelt example isn't a 100% fit as seatbelt-opposers argued that seatbelts actually increase the risk of drowning, so they're not a security improvement but a trade-off. of course, cases of drowning in an automobile where the passengers would have survived without a seatbelt are incredibly rare, while all other accidents where seatbelts help are comparably common.
- pjmlp 3y agoThe book unsafe at any speed, is a good background on the resistance regarding security improvements in the car industry.
- dralley 3y agoI have doubts that would even be true. I'll gladly take a struggle to remove the seatbelt over receiving a head trauma immediately prior needing to escape the car and swim to safety.
- codeptualize 3y agoEven though I have no clue what this binder thing is or does I quite enjoy reading well written docs like this.
- happyweasel 3y agoLooking at the c code and comparing it with standard c++ (raii, smart pointers).. why not use c++? Sure rust has additional safety features that alone is worth it but they were mentioning ref counting,locking , bounds checking,error handling .. most of that is doable with pedestrian c++
- nercury 3y agoFirst and foremost, algebraic data types, specifically, proper sum types, called "enums" in rust. Think safe C unions or sane C++ variant. Everything is built on them, they help to encode various states and ensure they aren't misused. Second, moves by default. They make building wrappers that depend on creation and destruction of a value much easier. They can track various things: memory usage, threads, temporary pointers, or whatever else. Unlike unique_ptr, they are on stack and part of the type system.
- ansible 3y agoLinus Torvalds famously does not like and will not allow the use of C++ in the Linux kernel. Also, Rust explicitly puts safety first, and C++ cannot give the same guarantees for normal code. The uses of `unsafe` in Rust should be relatively uncommon and deserve extra scrutiny.
- dig1 3y ago> C++ cannot give the same guarantees for normal code Can you give me example of a normal C++ code where compiler and/or language will not guarantee safety? Let's put aside UBs, because they are everything but normal code.
- Tyr42 3y agoAllows you to modify containers while iterating.
- nercury 3y agoI would avoid saying that it's "Rust" that "gives guarantees". It paints Rust as this magical thing that will solve anything. My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. The idea is to solve hard problem once, and reap the benefits many times. But it all depends on wrapper author. In that regard, it is perfectly possible to write horrible Rust code.
- auselen 3y agoI didn’t know Binder is upstream. Is it really?
- goodthenandnow 3y agoYes, since quite some time.
- goodthenandnow 3y agoTrivia: Fuchsia's starnix also has its own implementation of binder [1] and it's written is Rust too (as are most Fuchsia components). [1]: https://cs.opensource.google/fuchsia/fuchsia/+/main:src/starnix/kernel/device/binder.rs https://cs.opensource.google/fuchsia/fuchsia/+/main:src/star...
- vitiral 3y ago> Additionally, we've been able to use the more expressive type system to encode the ownership semantics of the various structs and pointers, which takes the complexity of managing object lifetimes out of the hands of the programmer, reducing the risk of use-after-frees and similar problems. I find statements like this humorous. Who is "the programmer" in the above sentence, is it the "it" in "it is raining"? It doesn't take it out of the hands of the programmer, it separates/delegates it to the programmer creating the types vs the programmer creating the implementation. They might be the same programmer and that programmer might be very happy they could separately encode such checks, but it doesn't take it out of anyone's hands.
- dralley 3y agoIt takes the burden of remembering the interactions between lifetimes across the entire system out of the programmer's hands. Sure, they still have to write the code that denotes the lifetimes, and they have to make sure the code continues to compile. But they don't have to remember that an object passed into some function call might be free'd inside a conditional 3 function calls deep
- vitiral 3y agoI don't believe the source was talking about lifetimes but rather creating clever types regarding ownership. Some "programmer" must still construct said types. I would agree that lifetimes are taken out of "the programmer's" hands in Rust for all "programmers" who are not working on the Rust lifetime compiler :D
- Xeamek 3y agoI am somewhat suprised binder is part of upstream; Are there any other projects aside of Android where binder is used? Could I theoretically use it in my linux program just like any other IPC mechanism?
- goodthenandnow 3y ago> Could I theoretically use it in my linux program just like any other IPC mechanism? Yes, absolutely. However, binder is implemented as a kernel module not enabled by default, so it depends on the build time configuration of your system's target kernel (eg., your distro's). That given, it's important to note that the binder driver/module is just one piece of a greater framework and it's raw IPC features aren't as simple to use as SysV or POSIX's. For example, it requires a userspace process called context (or service) manager. Android has 3 different binder device instances and it builds a big framework on top of them wiring things like an interface definition language (AIDL), a set of libraries and SELinux permissions.