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

61–70 of 606 posts

Re: Memory Safe Languages in Android 13

#61

Post by est31 »

goodpoint wrote: post #20

I'll be downvoted for pointing out that comparing C++ with Rust without further context can be made into a false dichotomy. Some people are posting the article around the Internet as evidence that Rust solved security. Instead, there are many other memory safe languages around and there has been thousands in the past. Additionally, many security issues are not due to memory safety. Please keep that in mind when makin…

> there are many other memory safe languages around and there has been thousands in the past.

Yes, and in fact they write about how they are replacing C/C++ with Kotlin or Java. All three are memory safe languages. But Rust is the only low level language of the three. This is Rust's killer feature. Of course, JavaScript is memory safe and so is Lua. But they are high level languages.

> Additionally, many security issues are not due to memory safety.

I think it depends on the domain the program is in. If you are a program managing some security property, like e.g. TLS encryption, then virtually any bug you have might be a security issue. Same goes for OS kernels. But if you are e.g. an image decoder library, then there is little security impact if your output is a weirdly colored image. But memory safety issues might still be a problem for your decoder library.

Overall the number being cited is 70/30, as in, 70% of security issues are memory safety ones, and 30% are ones which are not about memory safety.

https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

So you can reduce the number of security issues by 70%, isn't that great?

Re: Memory Safe Languages in Android 13

#62

Post by pornel »

LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe.

However, I appreciate that Rust tries to achieve safety through improving program correctness, not merely crashing sooner.

Of course Rust has run-time panics (hasn't solved the halting problem yet), but it also has many patterns catching problems at compile-time. For example, a hardened allocator can detect use-after-free bugs when they happen, but borrow checking can prevent them from existing in the code in the first place.

Re: Memory Safe Languages in Android 13

#63

Post by masklinn »

burntsushi wrote: post #45
codedokode wrote: post #32

Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.

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…

An other thing to note is that java does not check for overflow either. Having the “native” langage be no worse than the “managed” one is a better situation to be in than the reverse.

Also Rust allows enabling overflow checking in release, it’s a perfectly valid configuration.

Re: Memory Safe Languages in Android 13

#64

Post by Decabytes »

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 clear to me that Memory Safe Languages which ever they may be are the future.

I don't need to program in an environment where a systems programming language is required, so for me a languages debugability and introspective capabilities are the most important. So far I think Pharo hits the sweet spot for me, but it still has a long way to go documentation wise before I think it will see any sort of adoption. I'm rooting for it though.

Re: Memory Safe Languages in Android 13

#65

Post by burntsushi »

pclmulqdq wrote: post #56
insanitybit wrote: post #23

Earlier quoted context omitted.

No language in use meets your definition of memory safe.

Ada seems to fit.

Ada has no "unsafe"? Ada has no ffi? Ada has no escape hatches or unchecked APIs whatsoever? Does it have any pragmas that can disable safe checking? Because if it does, it's not "entirely" memory safe.

Re: Memory Safe Languages in Android 13

#67

Post by pcwalton »

heather45879 wrote: post #24
cjg wrote: post #2

Nice: "it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production"

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). :)

Re: Memory Safe Languages in Android 13

#68

Post by raphlinus »

cyber_kinetist wrote: post #18
insanitybit wrote: post #8

Glad to see robust work here. This strongly supports what should already be obvious, but sadly is not always understood; that memory safe languages are radically safer than memory unsafe languages. The impact is blatantly demonstrated here.

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.

The blog speaks to this explicitly, in the "what about unsafe Rust" section. The tl;dr is that the number of unsafe sections is a small fraction of the total code size, and it's much easier to audit the usage of unsafe, as the reason to justify it is focused. Thus, the use of unsafe in Rust is not a significant driver of actual vulnerabilities.

I think this has always been the goal, but it wasn't obvious at the outset that it would be achievable. The fact that we now have empirical evidence in real shipping products is significant.

Re: Memory Safe Languages in Android 13

#69

Post by dist1ll »

LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

What I like about this language is the crazy amount of creative and insightful discussions about language features and stabilization.

It's because Rust hits the spot for MANY different domains and people. System programmers, functional programmers, backend, db engineers, GUI, devs from the formal verification/mission critical camp, OS devs, graphics and even frontend with WASM.

For me personally, the thing I miss in Rust is better const fn/comptime/metaprogramming (like in C++). Without them, I find writing generic high-perf data structures quite tedious (and proc macros just aren't a suitable replacement for generics)

Re: Memory Safe Languages in Android 13

#70

Post by est31 »

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 Rust project itself it's hard to have an overview over everything that's happening (but it's still possible to some degree).

Post reply on HN