5 ms·

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 m

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?

pjmlp 2y ago
It is ongoing, https://source.android.com/docs/setup/build/rust/building-rust-modules/overview https://source.android.com/docs/setup/build/rust/building-ru...
cyberax 2y ago
There's actually a reimplementation of Binder in Rust, for Linux: https://lwn.net/Articles/953116/ https://lwn.net/Articles/953116/
- Nereuxofficial 2y ago
  And furthermore, it is by a Google employee with plans to merge it into Android as far as i know
chc4 2y ago
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.
resource_waste 2y ago
It wasnt found in the wild... unlike Pegasus.
refulgentis 2y ago
> 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)
- freedomben 2y 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.
  - refulgentis 2y ago
    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
vitiral 2y ago
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.
- chc4 2y ago
  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.
userbinator 2y ago
Keep advocating for security, until it turns against you. Insecurity is freedom.
- kaba0 2y ago
  What an insanely dumb take.
  - userbinator 2y ago
    I guess you haven't had the experience of either seeing your work being used against you, or been under the threat thereof.
    - saagarjha 2y ago
      Been there, done that. Guess who can use memory corruption :)
  - autoexec 2y ago
    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.
deleted 2y ago
[deleted]

pjmlp 2y ago

It is ongoing, https://source.android.com/docs/setup/build/rust/building-rust-modules/overview https://source.android.com/docs/setup/build/rust/building-ru...

cyberax 2y ago

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

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

chc4 2y ago

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.

resource_waste 2y ago

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

refulgentis 2y ago

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

freedomben 2y 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.
- refulgentis 2y ago
  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

vitiral 2y ago

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.

chc4 2y ago
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.

userbinator 2y ago

Keep advocating for security, until it turns against you. Insecurity is freedom.

kaba0 2y ago
What an insanely dumb take.
- userbinator 2y ago
  I guess you haven't had the experience of either seeing your work being used against you, or been under the threat thereof.
  - saagarjha 2y ago
    Been there, done that. Guess who can use memory corruption :)
- autoexec 2y ago
  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.

deleted 2y ago

[deleted]