Why no Go?
I'm guessing if you don't need something low-level/c-compatible in Android you'd reach for Java/Kotlin since it's already engrained in the ecosystem.
Memory Safe Languages in Android 13
41–50 of 606 posts
Re: Memory Safe Languages in Android 13
#42The more interesting part of this article for me is that in 2022, Java is still the number 1 language that new pieces of Android are made out of. It probably has to be this way for compatibility, and I personally have no problem with Java. But the hype train would not have you believe this.
Re: Memory Safe Languages in Android 13
#43Why no Go?
The GC I guess ? Rust is mostly replacing the C & C++ code that is pretty low-level in the OS where a GC is not desirable or even usable.
Re: Memory Safe Languages in Android 13
#44I'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…
Preemptively complaining about downvotes is a great way to get downvotes.
That doesn't make you a martyr.
Re: Memory Safe Languages in Android 13
#45Rust 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 exploit, such as a buffer overrun. But Rust uses bounds checking by default everywhere, so the worst case you'll usually end up with here is a panic or a DoS vulnerability. Not great, but probably preferable to other types of vulns that grant access to sensitive data.
So I think two things would need to happen, at minimum, to get a non-DoS vulnerability here. You'd need to find a bug that caused arithmetic to overflow where it otherwise shouldn't, and you need to find some way to connect that to an explicitly `unsafe` unchecked access into memory.
Re: Memory Safe Languages in Android 13
#46Earlier 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.
It seems unlikely that it's the double colons and the angle brackets that hold people back from migrating from C and C++ to Rust.
Yeah Rust's syntax was inspired to be similar to C++.
Re: Memory Safe Languages in Android 13
#47Earlier 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).
Yep, ctypes is part of the stdlib and lets you corrupt the VM on the fly. Fun stuff like changing the value of cached integers and everything.
But ctypes being a terrifying pain in the ass, people tread very carefully around it. Cffi’s a lot better though it requires an external package. At the end of the day I think I’d be more enclined to bind through pyo3 or cython than write C in python (which is what ctypes has you do without even what little type system C has, to say nothing of -Wall -Weverything).
Re: Memory Safe Languages in Android 13
#48Nice: "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 do agree that Rust sometimes has a lot of visual noise.
But that use statement is not a good example of it, and if that's the biggest criticism then Rust is faring fantastically well.
Re: Memory Safe Languages in Android 13
#49Glad 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…
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 have a vuln where you could specify a relative path that could escape and write anywhere in the receiver's filesystem. Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language. But the threat surface I had to be scared about was much smaller than it would have been in other languages. And because the fallible APIs are obvious, I handled many edge cases that I might have forgotten about otherwise.
Re: Memory Safe Languages in Android 13
#50Not 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?
Rust programs can have vulnerabilities, but thankfully the fuzzer scene is well developed. Recently a memory safety bug was found in a Rust library (that used unsafe) and it turns out the original C++ implementation had it too. So here, fuzzing the Rust rewrite led to improvements in the original C++ library. I guess it's because there is higher interest in increasing the safety of Rust programs.
https://dwrensha.github.io/capnproto-rust/2022/11/30/out_of_...