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

161–170 of 606 posts

Re: Memory Safe Languages in Android 13

#161

Post by cesarb »

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…

> It has unsafe escape hatches (via ffi, at the very least).

Playing devil's advocate, I can think of at least one language which has no escape hatches: Javascript running within a web page.

Re: Memory Safe Languages in Android 13

#162

Post by masklinn »

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. Both of them have their runtimes written in C/C++.

Technically, pypy is a Python runtime written in Python.

Re: Memory Safe Languages in Android 13

#163

Post by manbart »

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.

How about in the OS? This sounds like exactly the type of thin SELinux is meant to handle

Re: Memory Safe Languages in Android 13

#164

Post by nneonneo »

TheNorthman wrote: post #143
bluGill wrote: post #117

Earlier quoted context omitted.

I've only started scratching the surface, but that rust really wants you to use Cargo, while we have our own homegrown package manager, and cmake creates a lot of friction. I can tell you that bad programmers can write bad code in Rust.

> I can tell you that bad programmers can write bad code in Rust. Of course. The question rust users seem to put forth is that bad programmers write _better_ (not good) rust code than C code. That bad programmers write bad code is to expected. That is, after all, a likely explanation for why they're bad.

I would argue that the type system does make it somewhat more difficult for bad programmers to do egregiously bad things in the language. A carefully written library can be quite difficult to misuse (at least, without panics or using unsafe code in the user code, both of which are easy to catch in code review).

Rust has no null/nil pointers. Instead, it has nullable types (Option), which are harder to misuse. If you want to "dereference" a Option, you either use unwrap() (which panics) or you handle the None case properly. While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages, a code review can catch misuse of .unwrap() much more readily than a missing null/nil check.

As another example, the Send/Sync traits provide strong guarantees about thread safety; using these traits properly lets you make data structures that cannot be misused in a multithreaded program. Although deadlock is still possible (hello, halting problem), many types of data races are simply eliminated.

Re: Memory Safe Languages in Android 13

#165

Post by masklinn »

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.

> We did a big improvement, but why can’t we disable “unsafe”?

Because there are things which literally can not be safe, and rust will not let you get away with pretending.

Re: Memory Safe Languages in Android 13

#166

Post by alserio »

dahfizz wrote: post #137
burntsushi wrote: post #85

Earlier quoted context omitted.

I suppose reasonable people can disagree, but I don't think it's anywhere near as clear cut as you seem to be implying. You talk about data structures in std using unsafe, but you don't mention the heaps and piles of C code used to implement CPython's standard library. It's not like you need `unsafe` in Rust to build every data structure. I build oodles of data structures on top of the fundamental primitives provided…

You make a good point that much of pythong stdlib is implemented in C. But you could implement python's list in pure python, safely. You can't implement something like that in rust without unsafe.

How would you implement a python list in python? I mean, what would you consider "acceptable" primitives to do so?

Re: Memory Safe Languages in Android 13

#167

Post by mcronce »

estebank wrote: post #49
stonemetal12 wrote: post #39

Earlier quoted context omitted.

When Heartbleed was a topic of discussion, some pointed out that Rust wouldn't have 100% protected from that vulnerability. So it is good to see some proof that using a safer language does in fact pay off in terms of fewer defects. I just wish there were some info around cost associated with development effort. Did the Rust code take longer to develop? If initial development was longer, what if we include time saved…

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.

It didn't on its own, but it is worth noting that with type-safe languages, you can protect yourself from this by encoding that invariant into the type system.

Using Rust as an example, take a &std::path::Path (or &camino::Utf8Path or whatever) in your public API; have custom InternalPathBuf and InternalPath types that perform validation to ensure they aren't using relative paths to "break out" during construction, and then pass those around in your internal API. Bingo bango, now there's no way (short of transmuting, an `unsafe` operation) to pass invalid paths to the functions that hit the filesystem without a compile error. No redundant runtime checks required, and no need for you as the developer to keep track of which codepaths have already validated a Path and which haven't.

I'm sure you already know this, and I would imagine that Java can do the same, but it's a big step above languages like Python where you can do whatever you want to anything you want.

EDIT: lol while I was typing this you made a post about the same thing below.

Re: Memory Safe Languages in Android 13

#168

Post by modshatereality »

insanitybit wrote: post #154
modshatereality wrote: post #115

Earlier quoted context omitted.

You should at least wait until there is more than one working/usable compiler for the language if you're going to start making systemic changes to your multi-billion-dollar code base responsible for the commerce of multiple billions of people on the planet. It's a weird move at this point for google to be making(edit: considering go is already supported on multiple compilers).

"It should have two compilers" is a pretty arbitrary benchmark for production readiness. I'd suggest the benchmark be based on, idk, something with any fucking meaning.

>something with any fucking meaning

So you claim to have a better metric, feel free to share it?

site broken and wont let me reply any more: "shipped into production" is meaningless, compilers are directly related to language community and complexity.

Re: Memory Safe Languages in Android 13

#169

Post by [deleted] »

optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

[deleted]

Re: Memory Safe Languages in Android 13

#170

Post by masklinn »

joshuamorton wrote: post #119
mk89 wrote: post #104

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believe…

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, the Rust project releases CVE for things other languages literally just shrug about e.g. https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html

The C++ people just go "lol nothing in std::filesystem is safe we don't give a shit". The spec pretty much says it's UB to have other programs interact with the filesystem: http://eel.is/c++draft/fs.race.behavior#1.sentence-2

Post reply on HN