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

181–190 of 606 posts

Re: Memory Safe Languages in Android 13

#181

Post by fiedzia »

selfmodruntime wrote: post #83
estebank wrote: post #49

Earlier quoted context omitted.

An example from an experiment to benchmark Rust and Java I did recently, where I sent files from one app to another: perf was good enough without tuning, with tuning I could triple the speed and final total time on both versions was comparable. Memory was much greater for Java (even with graalvm). The Rust version didn't suffer from any memory safety issues or race conditions when sending multiple files, but I did ha…

>Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language I'm still thinking about how we could integrate something like that in a language or the languages package manager. I'm unsure if it's possible.

It's possible and easy (have types for path coming from untrusted source), but it's a matter of a standard library rather than a language.

Re: Memory Safe Languages in Android 13

#182

Post by insanitybit »

est31 wrote: post #177
insanitybit wrote: post #153

Earlier quoted context omitted.

Not that it's important, but just a note that unless you recompile the standard library yourself, integer overflow will still be off for that code since it ships compiled. (Correct me if I'm wrong, that's my recollection).

The Android project compiles the standard library themselves: https://android.googlesource.com/platform/prebuilts/rust/+/a...

Figures, thanks.

Re: Memory Safe Languages in Android 13

#183

Post by masklinn »

optymizer wrote: post #152
selfmodruntime wrote: post #91

Earlier quoted context omitted.

> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in. Nope, that would be a static function on your struct. By using self you let the compiler know that you want to use an instance function.

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

Re: Memory Safe Languages in Android 13

#184

Post by masklinn »

nneonneo wrote: post #111
selfmodruntime wrote: post #91

Earlier quoted context omitted.

> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in. Nope, that would be a static function on your struct. By using self you let the compiler know that you want to use an instance function.

Also, there are several different ways to pass self: `self`, `mut self`, `&self`, `&mut self`, and they have very different semantics. Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. but I feel like the explicit `self` is very clear and easy to understand.

> Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc.

`fn Box foo()`? `fn Arc foo()`? It also requires more parser lookahead.

The `mut` case is also very odd, as it's not part of the function API (it just configures the binding of the internal local). Plus if self was implicit it likely would need to be a keyword, so that wouldn't be a usecase at all anymore.

Re: Memory Safe Languages in Android 13

#185

Post by fiedzia »

burntsushi wrote: post #25
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.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

> Is there any practical programming language that is memory safe in its "entirety"?

Whatever can be compiled to BPF meets this requirement. The price though is that it wouldn't be very useful.

Re: Memory Safe Languages in Android 13

#186

Post by throwup »

mk89 wrote: post #159
bluGill wrote: post #149

Earlier quoted context omitted.

Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.

If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.

Rust has a culture where people don't use `unsafe` unless absolutely necessary. That is generally good enough in my experience.

If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].

And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need.

https://github.com/rustsec/rustsec/tree/main/cargo-audit

https://github.com/rust-secure-code/cargo-geiger

https://github.com/crev-dev/cargo-crev

Re: Memory Safe Languages in Android 13

#187

Post by stonemetal12 »

selfmodruntime wrote: post #83
estebank wrote: post #49

Earlier quoted context omitted.

An example from an experiment to benchmark Rust and Java I did recently, where I sent files from one app to another: perf was good enough without tuning, with tuning I could triple the speed and final total time on both versions was comparable. Memory was much greater for Java (even with graalvm). The Rust version didn't suffer from any memory safety issues or race conditions when sending multiple files, but I did ha…

>Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language I'm still thinking about how we could integrate something like that in a language or the languages package manager. I'm unsure if it's possible.

In C++\Java this would be solved by a static analysis tool. For example Fortify covers this error.

Re: Memory Safe Languages in Android 13

#188

Post by nneonneo »

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?

Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do?

Here's another example. C++ lets you do this:

    long input;
    std::cin >> input;
    process(input);
and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or it cannot be parsed as an integer, `input` now contains undefined content. You'd need to remember to check the contents, or end up processing undefined memory values. You cannot make this error in Rust without a lot of contortions (e.g. unsafe).

Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs.

Re: Memory Safe Languages in Android 13

#189

Post by berkut »

masklinn wrote: post #158
kllrnohj wrote: post #120

Earlier quoted context omitted.

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…

> But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related) Gaming platforms have gotten a lot less lenient over time, and with pretty much every game these days having online components, "security isn't remotely a concern" has become a lot less true.

Sure, but then there's things like HPC / offline graphics / simulation (VFX/CG), where performance is the end-all concern (or memory efficiency sometimes at the expense of CPU time), and security isn't a concern at all there, with lots of things like random index lookups into sparse arrays / grids, etc. I know for a fact that bound checks do make a bit of a difference there, as the data's random, so the branch predictors are close to useless in that situation...

Re: Memory Safe Languages in Android 13

#190

Post by stouset »

mk89 wrote: post #145
IshKebab wrote: post #132

Earlier quoted context omitted.

Did you read this bit? > It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement. They found ~100 security issues in 45k packages. That's clearly better than C++.

I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware…

> I didn’t say it’s not an improvement.

You… almost literally did?

> I am happy that we are moving towards a future where there are less memory bugs, but… are we really?

Post reply on HN