8 ms·

This is not a constructive comment. Saying an entire OS "would have been safer on this language" is just trolling. Comment should be reported IMO.

by haggy 7y ago

pjc50 7y ago
The entire raison d'etre of Rust is that it can be safer in exactly these cases where C or C++ is unsafe, and aims towards their eventual replacement. This will take a couple of decades, but it's a worthwhile effort.
- zymhan 7y ago
  Sure but until someone demonstrates at least a basic PoC using Rust to replace some Android C code, suggesting that it can is just speculation at best.
  - zamalek 7y ago
    Google has: https://en.wikipedia.org/wiki/Google_Fuchsia https://en.wikipedia.org/wiki/Google_Fuchsia
    - zymhan 7y ago
      I'm certain that you cannot simply drop-replace an Android OS component with a Fuschia component. My point is, of course Rust is a memory safe language, and of course it would theoretically prevent overflow exploits, but throwing in "you should've used Rust" when this news is announced isn't helping anything. I am certain that Android devs are at least aware of Rust and it's benefits.
      - est31 7y ago
        > I am certain that Android devs are at least aware of Rust and it's benefits. There is still not a single Android ROM component that's written in Rust. Cuttlefish uses crosvm which is Rust based, but it's a VM for Android testing rather than a ROM component. So they aren't even ready yet to experiment with shipping small components in Rust. Same goes for Chrome btw, it currently has a "no Rust allowed" policy, which is IMO very sad. So yeah I think it's worthwhile to talk about why AOSP doesn't have Rust components yet, especially as patching is sadly not available (yet) for most deployed devices. Large fleets of devices will have the bug for eternity. Therefore, prevention of vulnerabilities becomes even more important, which Rust helps doing. Your program won't be free of them, but as I pointed out above, these bluetooth vulns fall into the class that safe Rust eliminates.
fulafel 7y ago
This is userspace code, it's a legit point to criticise use of a memory-unsafe language here. It's 2020 after all, 24 years after "Smashing the stack for fun and profit" and 24 years into the golden age of C exploits while safer practical systems languages have existed. And also a legit point to promote Rust, even if it's a little too new for this codebase.
- chungus_khan 7y ago
  The transition in perception of UNIX and C from being buggy, inconsistent, foot-gun-laden corporate messes to being treated like the immutable ancient ways has certainly been a trip.
  - sadfklsjlkjwt 7y ago
    Isn't that because Os's based on Linux don't share a single LOC with commercial Unices?
SQueeeeeL 7y ago
I mean, they did link to a bunch of source code spots... so it's not completely unconstructive.
eeZah7Ux 7y ago
...especially when the large majority of HN readers are already aware of rust "thanks" to the rust evangelism strikeforce.
- dx87 7y ago
  A day or two ago there was an embedded software developer here claiming that low-level C developers "know what they're doing", so any languages with built-in safety features impose unnecessary safety restrictions, and that since any software can have bugs, there is no reason to use anything but C. Once that kind of stubborn attitude dies out, maybe we'll stop seeing people leave comments saying "This could have been prevented if they had used language X".
- eeZah7Ux 7y ago
  The downvotes are really telling.
est31 7y ago
I've said nowhere that all of Android should be written in Rust. I've only said that had this specific component been written in Rust, the issues wouldn't have shown up. Of course the code base is old and predates Rust. But I think this vulnerability serves as an important lesson about which language to choose for new projects in the embedded area. Thus I'm very glad that Google uses Rust for its new OpenSK security key firmware. I hope that future versions of Android will adopt Rust, at least in newly written components. Some Google developed Android related projects are already using Rust, like Cuttlefish which uses crosvm.
ptx 7y ago
Since Android includes a deeply integrated Java implementation that they've put a lot of work into, which includes an AOT compiler, why wouldn't they write services like this one in Java?

This is not a constructive comment. Saying an entire OS "would have been safer on this language" is just trolling. Comment should be reported IMO.

by haggy 7y ago

This is not a constructive comment. Saying an entire OS "would have been safer on this language" is just trolling. Comment should be reported IMO.

pjc50 7y ago

The entire raison d'etre of Rust is that it can be safer in exactly these cases where C or C++ is unsafe, and aims towards their eventual replacement. This will take a couple of decades, but it's a worthwhile effort.

zymhan 7y ago
Sure but until someone demonstrates at least a basic PoC using Rust to replace some Android C code, suggesting that it can is just speculation at best.
- zamalek 7y ago
  Google has: https://en.wikipedia.org/wiki/Google_Fuchsia https://en.wikipedia.org/wiki/Google_Fuchsia
  - zymhan 7y ago
    I'm certain that you cannot simply drop-replace an Android OS component with a Fuschia component. My point is, of course Rust is a memory safe language, and of course it would theoretically prevent overflow exploits, but throwing in "you should've used Rust" when this news is announced isn't helping anything. I am certain that Android devs are at least aware of Rust and it's benefits.
    - est31 7y ago
      > I am certain that Android devs are at least aware of Rust and it's benefits. There is still not a single Android ROM component that's written in Rust. Cuttlefish uses crosvm which is Rust based, but it's a VM for Android testing rather than a ROM component. So they aren't even ready yet to experiment with shipping small components in Rust. Same goes for Chrome btw, it currently has a "no Rust allowed" policy, which is IMO very sad. So yeah I think it's worthwhile to talk about why AOSP doesn't have Rust components yet, especially as patching is sadly not available (yet) for most deployed devices. Large fleets of devices will have the bug for eternity. Therefore, prevention of vulnerabilities becomes even more important, which Rust helps doing. Your program won't be free of them, but as I pointed out above, these bluetooth vulns fall into the class that safe Rust eliminates.

fulafel 7y ago

This is userspace code, it's a legit point to criticise use of a memory-unsafe language here. It's 2020 after all, 24 years after "Smashing the stack for fun and profit" and 24 years into the golden age of C exploits while safer practical systems languages have existed. And also a legit point to promote Rust, even if it's a little too new for this codebase.

chungus_khan 7y ago
The transition in perception of UNIX and C from being buggy, inconsistent, foot-gun-laden corporate messes to being treated like the immutable ancient ways has certainly been a trip.
- sadfklsjlkjwt 7y ago
  Isn't that because Os's based on Linux don't share a single LOC with commercial Unices?

SQueeeeeL 7y ago

I mean, they did link to a bunch of source code spots... so it's not completely unconstructive.

eeZah7Ux 7y ago

...especially when the large majority of HN readers are already aware of rust "thanks" to the rust evangelism strikeforce.

dx87 7y ago
A day or two ago there was an embedded software developer here claiming that low-level C developers "know what they're doing", so any languages with built-in safety features impose unnecessary safety restrictions, and that since any software can have bugs, there is no reason to use anything but C. Once that kind of stubborn attitude dies out, maybe we'll stop seeing people leave comments saying "This could have been prevented if they had used language X".
eeZah7Ux 7y ago
The downvotes are really telling.

est31 7y ago

I've said nowhere that all of Android should be written in Rust. I've only said that had this specific component been written in Rust, the issues wouldn't have shown up. Of course the code base is old and predates Rust. But I think this vulnerability serves as an important lesson about which language to choose for new projects in the embedded area. Thus I'm very glad that Google uses Rust for its new OpenSK security key firmware. I hope that future versions of Android will adopt Rust, at least in newly written components. Some Google developed Android related projects are already using Rust, like Cuttlefish which uses crosvm.

ptx 7y ago

Since Android includes a deeply integrated Java implementation that they've put a lot of work into, which includes an AOT compiler, why wouldn't they write services like this one in Java?