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

231–240 of 606 posts

Re: Memory Safe Languages in Android 13

#231

Post by burntsushi »

codedokode wrote: post #128
burntsushi wrote: post #45

Earlier quoted context omitted.

There is some important context missing from your comment here. At least two points anyway: In Rust, overflow is not undefined behavior (neither signed nor unsigned). Today, arithmetic wraps in release mode (panics in debug mode), but it may panic in release mode in the future. The other point is that, since overflow wraps, that may indeed result in logic bugs. And in theory that logic bug could be used to lead to ex…

Wrapping arithmetic operations have been a reason of vulnerabilities in Linux kernel though. Developers need real addition, not addition modulo 2^32.

I don't understand if you're disagreeing with me or writing something that you think is inconsistent with what I said. Because I don't see anything inconsistent between what I said and what you wrote.

Re: Memory Safe Languages in Android 13

#232

Post by pornel »

est31 wrote: post #70
Decabytes wrote: post #64

Good to see some concrete evidence comparing memory unsafe languages to memory safe languages in an existing product. I just watched the Lex Fridman Guido Van Rossum episode and Rust vs C/C++ appears to be mirroring the trajectory Perl vs Python took in the ML/Bioinformatics space. Only time will tell whether Rust will reach the critical mass necessary to displace C/C++ in most new low level projects, but it appears…

> Only time will tell whether Rust will reach the critical mass necessary to displace C/C++ in most new low level projects As someone who has been in the Rust community since a couple of months after 1.0, I only see growth, year after year. At the start the community was small. Nowadays even the OSS part of it, which is a subset of the total community, is so big you can't have an overview of it any more. Even for the…

https://lib.rs/stats

crates.io downloads keep growing exponentially, although recently growth rate dipped from 2× to 1.9× (not sure if that's a trend or noise). Ratio of weekday to weekend downloads keeps going up, so presumably professional adoption of Rust keeps growing.

Re: Memory Safe Languages in Android 13

#233

Post by scj »

insanitybit wrote: post #23
cyber_kinetist wrote: post #18

Earlier quoted context omitted.

Rust (despite the common understanding) is not a memory-safe language in its entirety. It is a language designed to have a strict division of safe/unsafe which makes it easier for developers to compartmentalize code to achieve memory-safety.

No language in use meets your definition of memory safe.

Perhaps the problem is with the term "memory safe".

No language can prevent a person from allocating a writable buffer, then reusing it without cleaning it. Do that on a server, and you have step 1 to a security vulnerability.

If requests to allocate memory come faster than the garbage can be collected.

Or a data container holding many/large references that will never be used. The difference between that and a lost pointer in C are moot in a practical sense.

All of these _can_ be prevented. But it's programmer care, rather than the language, that prevents them. Hence, the term "memory safe" is inaccurate. "Memory safer" would be more accurate, but far less catchy.

Re: Memory Safe Languages in Android 13

#234

Post by estebank »

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.

New code includes rewrites, like the Bluetooth stack.

Re: Memory Safe Languages in Android 13

#235

Post by lolinder »

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.

The overwhelming majority of bugs of any sort live in new code. The longer a piece of code has been around, the safer it generally is (with occasional high-profile exceptions). This means two things:

1) The most cost-effective way to eliminate the majority of memory bugs is to just start writing all new code in a memory-safe language. If you were going to write new code anyway, you may as well do it safely.

2) Going back and re-writing existing code that doesn't need to be changed may solve latent memory bugs, but it will likely introduce other regressions that could be worse for security or for user experience. If code doesn't need to change, it's often better to leave it as is.

Not that a rewrite is never called for, but it's not necessarily the best course of action by any metric (even when neglecting the cost).

Re: Memory Safe Languages in Android 13

#236

Post by metaltyphoon »

pcwalton wrote: post #67
heather45879 wrote: post #24

Earlier quoted context omitted.

The problem with Rust is the language syntax is ugly. It has a ton of visual noise. I think folks who write languages should have a typographer on their team because something like this: use std::collections::HashMap Is a typographic nightmare. While I understand “form follows function”, it’s tough to be excited to program in something like this.

I was responsible for that decision, and I'm also a typographer (worked for years on vector rendering of fonts). :)

What reason were used to not use what C# has? It’s infinitely less noisy than Rust’s ::

Re: Memory Safe Languages in Android 13

#237

Post by the_myth »

hknmtt wrote: post #206

programming language developers always made compilers to just do that - compile the code. without actually checking the code for problems and allowed programmers to write faulty code. and now we have accepted these memory leaks and shooting oneself into one's foot as normal. so instead of investing time to make compilers output safe programs we had to wait for rust to come by and its "first time in history" compiler…

I mean, rust devs are couple of nobodies and I don't think they just let nobodies in on the C++ committee.

Re: Memory Safe Languages in Android 13

#238

Post by ghostwriter »

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…

> 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 existing capacity to port/rewrite big codebases in entirely new stacks. The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases.

Re: Memory Safe Languages in Android 13

#239

Post by oll3 »

netr0ute wrote: post #171
nneonneo wrote: post #122

Earlier quoted context omitted.

Unclear what you mean by user input - for arguments, `std::env::args()` exists, and for stdin `std::io::stdin()` exists and provides various read functions. let mut line = String::new(); stdin().read_line(&mut line)?; println!("input: {}", line); I suspect that there _have_ been some changes since you last looked - for example, the ? operator lets you propagate errors in a more compact way.

let mut line = String::new(); stdin().read_line(&mut line)?; This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do std::string input; std::cin >> input; and have it Just Work. Why can't Rust do something similar?

Not that this kind of stdin reading operation is something I do often. But at least the Rust code says what it does. Bitshifting stdin by a string on the other hand... Does it read a line, or forever, or read at all? I wouldn't call it the ultimate syntax for a line reader anyway. :)

Re: Memory Safe Languages in Android 13

#240

Post by Gankra »

kllrnohj wrote: post #211
Gankra wrote: post #174

Earlier quoted context omitted.

there's almost no bounds checking in rust code before the optimizer even looks at it because we use iterators and not goofy manually indexed for loops that are begging you to make a typo that crashes your code :)

Yeah but idiomatic modern C++ is also using iterators and even before that there's no bounds checking to eliminate in the first place since operator[] is unchecked so the optimizer can't be struggling to eliminate it since it's not there. The question isn't "does Rust have bad bounds checking optimizations" but rather "what is this mythical heavily-bounds-checked C code that the compiler can't optimize away?"

No the claim is always that Rust "must" be slower than C/C++ because it has pervasive bounds checking for array indexing.

Then people insist on wanting to replace every x[i] in prod with x.get_unchecked(i) only to learn that, not only was that indexing not slowing the code down (the branch is perfectly predictable in a correct program!), but actually any difference is so in the noise that the random perturbation is worse (or that the asserts were actually adding extra facts for more profitable optimizations in llvm).

There is definitely specific hot loops with weird access patterns where it can be high impact but those are the exception, not the rule, as the Android team demonstrated.

Post reply on HN