Hacker News Reader

Comment by doodlesdev | Hacker News Reader

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?

View on HN

> 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.

Fuchsia saw cuts but still has people working on it.

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.

There's actually a reimplementation of Binder in Rust, for Linux: https://lwn.net/Articles/953116/

And furthermore, it is by a Google employee with plans to merge it into Android as far as i know

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.

It is ongoing,

https://source.android.com/docs/setup/build/rust/building-ru...

Keep advocating for security, until it turns against you.

Insecurity is freedom.

What an insanely dumb take.

I guess you haven't had the experience of either seeing your work being used against you, or been under the threat thereof.

Been there, done that. Guess who can use memory corruption :)

I can't say it's appropriate in this context, but it is true in others. Generally, freedom means having enough rope to hang yourself with.

It wasnt found in the wild... unlike Pegasus.

Reply on news.ycombinator.com