Binder is actually something that was designed for BeOS and PalmOS, so ironically it is not very tied to Linux and IMHO one of these technologies that Google uses to abstract themselves from Linux.
(It still has something to do with the early implementations since I recognize some of the #define names..)
It also provides a way for a pseudo-microkernel like architecture despite Linux, as many services run on their own process talking with the Linux kernel via Binder.
IIRC, Binder also still includes "passing" the scheduler quanta between procese6when making a call - meaning that when you make a call from process A to process B, instead of waiting for process B to be scheduled for execution, it is swapped in place of process A in scheduling - effectively, process A "pays" for the CPU tone that process B needs to service the call.
After extra checking, yes, they hack around a lack of infrastructure on kernel through tricks with setting nice values - I do know of patches that implement more, but they ultimate never got upstreamed
Which makes me wonder how does one read up on kernel internals outside of just perusing all the code, how do you get all the wonderful history that is just lost unless you talk to someone who worked on it or find an insightful comment on HN. The one thing version control should emphasize more of is a way to go back through commits and let people (probably approved people) comb through and comment the code in a metadata way that the version control software can display without affecting commits. Would be neat to peruse code, hover (if you have a good editor / IDE ;) and see commentary by others on said code.
And again an extremely serious, device-compromising vulnerability, arises from a use-after-free. When will we learn?
I don't think I'll ever be able to trust modern devices until we finally abandon memory-unsafe languages. It's such low hanging fruit at this point I don't understand anymore why OS developers keep investing their time in other parts of the threat model of operating systems if memory usage vulnerabilities keep arising that completely destroy the existence of any security layer in the system.
Was Google's plan to replace Android with Fuchsia? Is there any plan to get rid of these vulnerabilities (specially use-after-free) at scale on Android like the Chrome project has attempted with the MiraclePtr project?
> Was Google's plan to replace Android with Fuchsia?
One of the oddities of BigCo and diffusion of responsibility / abdication of intent is, I'm not sure there's one single person who could accurately answer this.
I hate coming out and saying it because I'm a xoogler, and I'm worried people will think I'm breaking new territory by saying this, but it's known outside Google at this point: no. Never say never, but, it's as close to no as you can get.
Given:
- Nest Hubs were/are the only shipping Fuchsia product and are de facto deprecated for Pixel tablet
- Assistant is de facto deprecated for Gemini (Assistant was responsible for Nest Hub's UI, which hasn't seen even minor updates in years)
- what I see occurring on Google's Blind re: multiple Chrome OS engineers confirming they were told to chill out and wait for reprioritization, and a handful expressing it is dead and they're expecting to be transferred to Android desktop work
- Flutter and Fuchsia have both been reported to have firings, whereas Android has had none reported.
- Hiroshi Lockheimer left recently, so now the hardware head owns Android/Chrome OS/Fuchsia.
This all plays along well with what Sundar spends his time on and drags on, and on, and on: about efficiency and focus, meaning, please cull 5-10% of your workers yearly and you're not getting new headcount soon if ever. Because profit margins because Wall Street.
Thus, it looks like a hard decision by a genius leader to turn Assistant, Chrome OS, and Fuchsia into ghost towns staffed by a skeleton crew and reallocate headcount to keeping Android untouched/growing.
I'd be very surprised if Fuchsia ever shipped on anything new Google sells other than things clearly too resource-constrained for Android (speakers and non-ARM chips, i.e nest hubs)
> Was Google's plan to replace Android with Fuchsia?
I think the idea was that Fuchsia might replace Linux (so Android, ChromeOS, and various other OS things at Google would have a dependency on Fuchsia, instead of having a dependency on Linux)
But that seems unlikely now.
I think Fuchsia is pretty much dead, unless someone outside of Google starts using Fuchsia for something (e.g. Facebook almost used Fuchsia a few years ago)
Thanks, that's super interesting. Adding some simple grapevine anecdata, I've been told that even shipping Fuchsia on Nest hubs was more of a solution in search of a problem.
It's such an interesting thing. I'd say yes if I was with other googlers, because that's the most true answer.
On the other side, I'd say the short sighted thing was not being brave enough to keep going. I worked on Android, and _much_ prefer the Flutter stack*, to the point you could say that's part of the reason I left. I believe it's a revolution in dev efficiency.
That being said, Flutter doesnt need Fuchsia, and Fuchsia didn't need to replace the kernel on the hubs, and when it did, there were contemporaneous issues with the hubs being janky that just would have killed absolutely any practical argument for Fuchsia they would be having 6 layers above me.
* By Flutter stack, I just mean, flutter. a significant feature of my last 3 years there was being the dude on Android randomly writing flutter - I was doing high stakes UI prototyping and thought it was friggin awesome that it A) worked on web, so I could easily share things with designers without needing an android build B) used skia on web, so if it worked there, it was clear it could work on Android C) eventually when my stuff was cross-org regularly, a Flutter demo objectively set a floor for performance on any platform it might deploy it
I also really like Flutter and think the Flutter team has done a great job on the tech side. Google management, on the other hand, seems determined to do some very short sighted cost cutting and that makes a project like Flutter vulnerable.
Solution in search of a problem with buckets of seemingly unlimited headcount (at the time) and went and rewrote and discarded half of the stuff on the Home Hub we had already shipped Because Purity(tm).
Fuchsia is neat, but the politics of the whole thing and the absolute idiocy of rewrites for rewrites sake... Makes me not feel so terrible about their reduced headcount.
I never understood who cared enough to bet on the technical side, my understanding was the political weight was on the UX side. Curious for your input if you have any thoughts you're comfy sharing
I surmise either A) Hiroshi wanted a fresh OS without the political risk of committing to it in a well-known way and/or
B) I don't grok how free-wheeling Google could be prior to my arrival (late 2016), combined with general bureaucratic inertia of there not really being an incentive to eliminate things*
* that probably sounds funny, but IIRC most of the major public cancellations are when a big project gets shuffled under a VP who could give 2 craps, or rebrandings that people got too upset about
All the political stuff was way above my paygrade I only suffered from it.
Home Hub launched with a perfectly good HTML-based UI that ran great, and shipped to millions of devices. And then they immediately set about rewriting the whole thing in Flutter and then they had to pretend that Flutter existed for the thing, which it didn't and so that had to get written, too.
Large parts of the OS and services like binder DEFINE memory safety. They twiddle the bits to setup the MMU, as well as the functions and data structures for the allocator/etc. Binder, as I understand, is an interface that accepts internal pointers.
There is no automatic memory safety from a language like Rust here. It's not so simple.
Now, perhaps some part of the system could be defined in a memory safe language. That might be good. But not this part.
Well, sort of. There definitely have been bugs in Binder related to it incorrectly mapping physical pages, which it needs to be doing as part of its core behavior, and is essentially a logic bug with memory safety implications that Rust fundementally can't defend against. The bug highlighted in the article, and the vast majority of other historical Binder bugs, aren't that though: they are "normal" object lifecycle bugs, related to improper locking, resource cleanup, and error handling. Those bugs very much could be prevented almost entirely with Rust or any other memory safe resource management. In fact, they have rewritten Binder in Rust, with it being the example driver usecase for the Rust-in-Linux push.
Fuchsia's kernel is written in C++. It's much more a microkernel design, and so device drivers usually run as userspace processes and some of them are Rust, but the core kernel is not written in a memory safe language.
> The motivation for this design is that a client can send a transaction and then wait for a response with one ioctl syscall. In contrast, IPC with sockets requires two syscalls, send and recv.
What a great motivation. Oh wait, then you write your literal operating system and all services in Java of all languages.
I find Android's architecture so frustrating, all the wrong design decisions
Yeah, I read that and did a double-take. That seems like a pretty silly micro-optimization. Binder is indeed widely used on Android, but I wouldn't expect in tight loops or critical paths. Sure, syscalls aren't cheap, but I can't see this odd interface saving much. Just seems like a recipe for confusion and bugs.
Then maybe learn a bit about it, before you decide based on bullshit whether you like it or not? Not that anyone would care about your opinion even then, when you can’t even get right such a basic thing as what it’s written in — then you surely are an expert of the topic.
