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

221–230 of 606 posts

Re: Memory Safe Languages in Android 13

#221

Post by burntsushi »

fiedzia wrote: post #185
burntsushi wrote: post #25

Earlier quoted context omitted.

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.

Right, that's why I used the word "practical."

Re: Memory Safe Languages in Android 13

#223

Post by pornel »

Octokiddie wrote: post #81

> This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. and > As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time. For those working on C/C++ code bases, how does…

Wrapping of C libraries in a Rust interface works quite well, and makes them safer. For stable battle-tested libraries I think it's even preferable to rewrites.

Many informal rules of C libraries like: "don't call read() after close()", "pointer must never be null", or "keep this data alive for as long as the handle is in use" in Rust can be expressed using the type system, and enforced at compile time. Cleanup can be automated. This catches bugs in user code and shields the library form misuse.

Re: Memory Safe Languages in Android 13

#224

Post by burntsushi »

cesarb wrote: post #161
burntsushi wrote: post #25

Earlier quoted context omitted.

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.

Yes, but that's not just a language. It's a language within a certain context. But it is a worthy mention.

Re: Memory Safe Languages in Android 13

#225

Post by harry8 »

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…

Seems like drawing too many conclusions from evidence while arguing against a straw man?

Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument.

The one that really bothers me in all these language-booster discussions (that we should and need to have) is the functional programming formal verification claims. We have no ssl library written in a memory-safe, functional language that has been proven correct that has dominated the space. Heartbleed wasn't yesterday.

I look down the list here: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati...

And I think something is not being discussed as far as replacing memory unsafe languages of critical security infrastructure. What is it?

Re: Memory Safe Languages in Android 13

#226

Post by berkut »

lynndotpy wrote: post #213
berkut wrote: post #189

Earlier quoted context omitted.

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

Security is absolutely a concern in these areas (except maybe offline graphics). In my experiences with university HPC clusters, security is very important because you have a lot of young students with no Unix experience accessing the resources. We've had real compromises of individual research machines because of this. This happens all the time at research universities, but it's not always public. In one public exam…

That's security of the generic infrastructure the code's running under though is it not? It's not security of say CUDA kernel code being executed on a GPU?

I'm talking about the actual HPC algorithm code heavily priortising performance (or in some cases memory efficiency), at the expense of pretty much everything else (other than correctness, obviously).

Re: Memory Safe Languages in Android 13

#227

Post by burntsushi »

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.

You certainly can! And that's a good example, because it exposes just how important context is to this discussion. Perf matters in certain contexts. If you implemented a list in pure Python, do you think its users would find the overall perf of Python to be acceptable?

Re: Memory Safe Languages in Android 13

#228

Post by rob74 »

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.

Re: Memory Safe Languages in Android 13

#229

Post by estebank »

mcronce wrote: post #167
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. 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 InternalPathBu…

Great minds and all that :)

I guess it is also an often used square peg that fits really nicely in the square Rust typesystem hole (no, not talking about those typed holes, haskellers).

Re: Memory Safe Languages in Android 13

#230

Post by optionalsquid »

nneonneo wrote: post #164
TheNorthman wrote: post #143

Earlier quoted context omitted.

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

> While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages

I think it is also worth noting that unwrap itself is much safer than an unguarded `x->foo()`, since it doesn't involve undefined behavior. Meanwhile an unguarded `x->foo()` allows compiler to assume that x is never null and consequently do things that the programmer wouldn't expect. The recent post on undefined behavior [1] had a (to me) quite shocking example of that [2]. So while bad Rust programmers misusing unwrap get crashes, they won't get nasal demons.

[1] https://news.ycombinator.com/item?id=33771922

[2] https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

Post reply on HN