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

31–40 of 606 posts

Re: Memory Safe Languages in Android 13

#31

Post by nequo »

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…

This seems like a straw man. Who said that Rust is the only memory-safe language? The title of the post itself uses "languages" in plural.

Re: Memory Safe Languages in Android 13

#33

Post by LAC-Tech »

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 simplifies a lot of stuff and lets you make cyclical data structures without a lot of hoop jumping.

Re: Memory Safe Languages in Android 13

#35

Post by Manishearth »

goodpoint wrote: post #22
onei wrote: post #17

Not being aware of how vulnerabilities are detected and despite being a big fan of Rust, I wonder if there are other variables that drive down the ability to find bugs in the short term. If a researcher is only familiar with C and C++, is it possible that they're just ill equipped to find similar bugs in Rust?

Not only that, they are also comparing new code with pretty old code.

They're also explicitly tracking new code by language, and talking about memory safety vulnerabilities per year, and they also link to [1] which talks about how most memory safety bugs they get are in new code.

Most of the graphs here are about new code.

[1]: https://security.googleblog.com/2021/04/rust-in-android-plat...

Re: Memory Safe Languages in Android 13

#36

Post by warkdarrior »

Manishearth wrote: post #30
heather45879 wrote: post #24

Earlier quoted context omitted.

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 always say that if the strongest complaint people have about your language is syntax; you've already succeeded.

You have an extra semicolon in your comment.

Re: Memory Safe Languages in Android 13

#37

Post by goodpoint »

kangalioo wrote: post #28
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…

But I think other memory safe languages don't have C++-like performance, right?

There's been many, for example Ada/SPARK, D, Nim, Java, Kotlin, Swift.

Re: Memory Safe Languages in Android 13

#38

Post by cryptonector »

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizers, runtime mitigations, and hardware protections. Unfortunately, these all negatively impact code size, memory, and performance.

Even more evidence that the negative performance impact of bounds checking is minimal, nay, it can even be positive.

Re: Memory Safe Languages in Android 13

#39

Post by stonemetal12 »

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.

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 from reduced effort for bug resolution?

Re: Memory Safe Languages in Android 13

#40

Post by maeln »

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.

This is how I discovered that one of my code was "bugged". I had to implement a driver for an obscure chinese-made machine with a documentation google translated. In the protocol, there was a check byte and the explanation says that it was the 100 modulo of the sum of all previous byte. They didn't mention overflow. I tested it using a release build and it was working. Later on, while changing a few thing, I notice that the debug build was not working. I quickly find that this was because of the overflow behavior.
Post reply on HN