Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

271–280 of 606 posts

Re: Memory Safe Languages in Android 13

#271

Post by ghostwriter »

Ar-Curunir wrote: post #255
ghostwriter wrote: post #238

Earlier quoted context omitted.

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about exis…

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

> If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because . After all, there are greenfield projects that are being started in C++20 and people are enthusiastic about their prospects. I wouldn't just blindly dismiss their reasons in favour of Google ones.

Re: Memory Safe Languages in Android 13

#272

Post by _fullpint »

dist1ll wrote: post #69
LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

What I like about this language is the crazy amount of creative and insightful discussions about language features and stabilization. It's because Rust hits the spot for MANY different domains and people. System programmers, functional programmers, backend, db engineers, GUI, devs from the formal verification/mission critical camp, OS devs, graphics and even frontend with WASM. For me personally, the thing I miss in…

I write a lot of Rust these days and unfortunately really great FP stuff is pretty damn cumbersome to write.

Re: Memory Safe Languages in Android 13

#273

Post by afdbcreid »

masklinn wrote: post #179
throwup wrote: post #114

Earlier quoted context omitted.

So many complaints above surface-level syntax here. > press "shift 3 bracket shift 9 shift 0 bracket" at the top of my structs Just use an IDE and you can press alt+enter. Same thing you do in Java when writing getters and setters for your AbstractFactoryBeans. > "let mut" could have been "var" The "mut" does not belong to the "let", it belongs to the variable name. let (read_only, mut read_write) = (1, 2); > Passing…

> Explicit is better than implicit. Not only that, but in Rust it actually has a meaning. Self can be &self or &mut self, which impacts the calling conventions. The alternative would be fully typing anything but owned method calls which would just not have a self parameter, which would be incredibly weird. It also shows that as in Python (and really even more so) "methods" are little more than syntactic sugar for fun…

It can also be `self: Box` or `mut self: Pin` or `self: Box>>` if you feel brave.

Re: Memory Safe Languages in Android 13

#274

Post by _fullpint »

kccqzy wrote: post #123
LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try: traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO () Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see htt…

The lack of HKT is the only disappointing thing about the lang for me.

There are some ways to get around it, by simulation and using ‘as’ but it isn’t particularly safe.

Re: Memory Safe Languages in Android 13

#275

Post by pjmlp »

kllrnohj wrote: post #131
dahfizz wrote: post #77

Earlier quoted context omitted.

I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.

> I think a distinction can be made in that you never really need to use unsafe operations in python or Java. You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++. So based off of this unusual line of reasoning, Rust is strictly more memory safe than either of those as it's at least possible to have a Rust program without any unsafe…

There are at least three Java runtimes written in Java, Jikes RVM, MaximeVM, and GraalVM.

Re: Memory Safe Languages in Android 13

#276

Post by LAC-Tech »

kccqzy wrote: post #123
LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try: traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO () Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see htt…

I guess what I really meant was - they've captured a lot of common patterns in the iterator library so I don't have to write them myself.

No experience with haskell - sometimes I try and learn it and give up when stack complains about version conflicts - but regardless I try not to get too many hangups about functions not being super generic, just that they are there when I need them.

Re: Memory Safe Languages in Android 13

#277

Post by Avamander »

latenightcoding wrote: post #250

I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities

Those aren't or haven't been available long enough to have a significant effect, I suspect.

Re: Memory Safe Languages in Android 13

#278

Post by chlorion »

kllrnohj wrote: post #120
cryptonector wrote: post #38

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…

No it isn't. It's just evidence that it's a trade-off you might want to make in order to achieve some other goal, specifically security. But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related), this is not at all evidence for changing anything. It could be that Rust's optimizer eliminates the bounds checking so regularly as to be a moot point, but this isn't say…

There were (or are?) some older call of duty games being sold on steam that had unpatched RCE vulnerabilities in them. Simply joining a server ran by a malicious host can result in the players system being totally compromised.

These games would go on sale once a year or whatever and attract new players, and people would post warnings in the steam forums and whatnot to try to stop people from being effected by the issue, but I am sure some people either didn't listen or didn't notice the warnings.

I haven't looked into the issue in a few years at this point, but it's very possible that the games are still unpatched and being listed in the store to this day.

Anything that connects to the internet needs to be strongly concerned about security!

Re: Memory Safe Languages in Android 13

#279

Post by aswanson »

ghostwriter wrote: post #271
Ar-Curunir wrote: post #255

Earlier quoted context omitted.

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

> If they’re saying that C++ can’t be saved, maybe they’re worth listening to. It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because . After all, there are greenfield projects that are being started in C++20 and…

C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.

Re: Memory Safe Languages in Android 13

#280

Post by brundolf »

rob74 wrote: post #228
lolinder wrote: post #116

Their notes about vulnerability severity are particularly interesting. Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle of switching to a new language. Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages…

...but still, even with Android's importance and Google's resources, they're not planning to "rewrite it in Rust", at least not for now - only new code will use Rust.

Mostly new code. They've rewritten some core, high-importance pieces. But any mature OS is a massive codebase, so it just wouldn't be feasible to systematically rewrite the entire thing indiscriminately
Post reply on HN