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

191–200 of 606 posts

Re: Memory Safe Languages in Android 13

#191

Post by berkut »

stouset wrote: post #176
kllrnohj wrote: post #140

Earlier quoted context omitted.

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

Trivially, anything using the Iterator trait. I don't know that I've ever actually manually indexed an array over years of using Rust.

In the HPC / offline graphics / simulation world, there's lots of things like sparse arrays / grids, where you index into compacted grids and iterators wouldn't be that practical in that scenario (i.e. one single item, although for things like filtering with surrounding cells they can still be useful sometimes), and bounds checks do make a bit of a difference there (it's definitely measureable above the noise threshold), and due to the random nature of the data, the branch predictors don't help avoid the overhead.

Re: Memory Safe Languages in Android 13

#192

Post by masklinn »

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?

Because Rust does not want to have implicit constructors, default constructors, constructors at all, random statics, ...

And `std::cin` does not read a line from the input, you need `getline` for that.

Re: Memory Safe Languages in Android 13

#193

Post by stouset »

berkut wrote: post #191
stouset wrote: post #176

Earlier quoted context omitted.

Trivially, anything using the Iterator trait. I don't know that I've ever actually manually indexed an array over years of using Rust.

In the HPC / offline graphics / simulation world, there's lots of things like sparse arrays / grids, where you index into compacted grids and iterators wouldn't be that practical in that scenario (i.e. one single item, although for things like filtering with surrounding cells they can still be useful sometimes), and bounds checks do make a bit of a difference there (it's definitely measureable above the noise thresho…

Sure, I know there's paradigms where manual indexing is important. GP asked for an example where bounds-checking could be eliminated in Rust, so I gave the first one I thought of.

Re: Memory Safe Languages in Android 13

#194

Post by tialaramex »

kllrnohj wrote: post #140
bluGill wrote: post #130

Earlier quoted context omitted.

I take it the opposite: C programmers out of abundance of caution of putting in bounds checks for code that will never be called with out of bound data. As such rust is eliminating code that is being manually written. If you don't write the bounds check in C, and rust for the equivalent determines that the bounds check isn't needed the code should be the same (to the assembly level). However if you write a bounds che…

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

I would guess all the aliasing stuff will get you. In C it's very difficult for the compiler to know whether two pointers are aliased, if we change X maybe Y changes too (because actually X and Y were the same). In Rust if we can write to it then it isn't aliased, and if we can't write to it then nobody can change it, thus changing X definitely can't change Y and the emitted machine code is sometimes simpler as a result, doing what you naively expected rather than what the C needs to do just in case you're crazy and there is an alias.

Now, in modern C you can say you don't have aliasing, but you're probably wrong and so there's a high risk when you do that you now get "impossible" bugs because you swore to the optimiser that if X changes, Y is unaffected, then created a situation where that wasn't true and now your program has no defined meaning, which is going to be tricky to debug. So, on the whole C programmers do not use this, indeed in places like the Linux kernel they even turn off the C standard's very minimal aliasing rules (which forbid aliasing objects of different types), they just don't trust themselves.

Re: Memory Safe Languages in Android 13

#195

Post by phaylon »

masklinn wrote: post #183
optymizer wrote: post #152

Earlier quoted context omitted.

what if there's no static function with that name?

There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box ) {} } impl Foo { // instance, refcounted fn foo(self: Rc ) {} }

Small nitpick: Fortunately, `Rc` and `Arc` actually don't require the nightly feature.

Re: Memory Safe Languages in Android 13

#196

Post by fiedzia »

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…

> You can't write any code at all in Python or Java without relying on unsafe operations.

There are Python interpreters written in other languages: there is one in Rust, and there is Jython and IronPython.

Re: Memory Safe Languages in Android 13

#197

Post by steveklabnik »

masklinn wrote: post #170
joshuamorton wrote: post #119

Earlier quoted context omitted.

Yes. They found 250 bugs after analyzing the entirety of rust and all of it's packages. There are probably more memory safety bugs in the python standard library and top 50k packages.

The rust project itself also has an extremely aggressive CVE policy (which many find too aggressive): if unsoundness is found in an API it gets a CVE, no matter how convoluted, and how unlikely it is to get into that situation, with absolutely no guarantee of any code in the wild coming even close to the unsoundness. Essentially, the Rust standard is that more or less every line of the C++ standard is a CVE. Hell, th…

Many CVEs in the Rust ecosystem aren’t filed by the Rust project itself. Anyone can file a CVE, it does not require involvement of upstream.

That said things that happen in the language or standard libraries like the one you linked, are often (but not always!) filed by the project.

Re: Memory Safe Languages in Android 13

#198

Post by [deleted] »

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…

[deleted]

Re: Memory Safe Languages in Android 13

#199

Post by yosefk »

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…

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry."

On top of that, memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportionately represent our most severe vulnerabilities. In 2022, despite only representing 36% of vulnerabilities in the security bulletin (NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages), memory-safety vulnerabilities accounted for 86% of our critical severity security vulnerabilities, our highest rating, and 89% of our remotely exploitable vulnerabilities. Over the past few years, memory safety vulnerabilities have accounted for 78% of confirmed exploited “in-the-wild” vulnerabilities on Android devices."

Re: Memory Safe Languages in Android 13

#200

Post by steveklabnik »

dahfizz wrote: post #144
kllrnohj wrote: post #131

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

By that logic, you can't write any safe rust at all because it relies on a compiler written in C++. We are discussing the languages themselves, not any particular implementation.

Only the codegen and many optimization parts of the compiler is in C++. The rest of it is in Rust.
Post reply on HN