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

141–150 of 606 posts

Re: Memory Safe Languages in Android 13

#141

Post by masklinn »

rraval wrote: post #101
masklinn wrote: post #47

Earlier quoted context omitted.

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

> But ctypes being a terrifying pain in the ass, people tread very carefully around it. I'm not sure how much people treading carefully actually translates into safety in practice. CPython in particular has ad-hoc refcounting semantics where references can either be borrowed or stolen and you have to carefully verify both the documentation and implementation of functions you call because it's the wild west and nothin…

> Here's a quick demo that deallocates the `None` singleton:

As I said, you can trivially corrupt the VM through ctypes. However I don't think I've ever seen anyone wilfully interact with the VM for reasons other than shit and giggles.

The few uses of ctypes I've seen were actual FFI (interacting with native libraries), and IME it's rare enough and alien enough that people tread quite carefully around that. I've actually seen a lot less care with the native library on the other side of the FFI call than on the FFI call itself (I've had to point issues with that just this morning during a code review, if anything the ctypes call was over-protected, otoh the update to the so's source had multiple major issues).

Re: Memory Safe Languages in Android 13

#142

Post by optymizer »

pcwalton wrote: post #112
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…

> Edit: if you downvote, reply with a link to the last compiler you wrote. https://github.com/rust-lang/rust/

upvoted <3

Re: Memory Safe Languages in Android 13

#143

Post by TheNorthman »

bluGill wrote: post #117
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…

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.

Re: Memory Safe Languages in Android 13

#144

Post by dahfizz »

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…

By that logic, you can't write any safe rust at all because it relies on a compiler written in C++.

We are discussing the languages themselves, not any particular implementation.

Re: Memory Safe Languages in Android 13

#145

Post by mk89 »

IshKebab wrote: post #132
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…

Did you read this bit? > It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement. They found ~100 security issues in 45k packages. That's clearly better than C++.

I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar.

Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware of what I am deploying. If on the other hand we want Rust to be the new JS for backend, then yes so be it, we improved over c++, well done.

Re: Memory Safe Languages in Android 13

#146

Post by bluGill »

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…

> Is there any practical programming language that is memory safe in its "entirety"?

This isn't possible. Eventually you are sitting at a block of memory and need to write the allocator. Maybe (like python) your allocator is written in C and you hide it, but there is always something that isn't memory safe sitting under your language.

You could write a language for an actual Turing machine which since it has infinite memory is by definition memory safe. However as soon as you need to run on real hardware you have to work with something unsafe.

You can of course prove a memory allocator is correct, but it would still have to use unsafe in rust. I supposed you could them implement this alloator in hardware, and make rust use that - but since this doesn't seem like it will happen I'm going with all languages have unsafe somewhere at the bottom.

Re: Memory Safe Languages in Android 13

#147

Post by kllrnohj »

goodpoint wrote: post #37
kangalioo wrote: post #28

Earlier quoted context omitted.

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.

I can't speak to the others, but Java & Kotlin do not at all have C++-like performance, especially not in anything beyond a toy level benchmark.

And even in those toy level benchmarks (like https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ), there's a clear divide between C/C++/Rust & everything else.

Re: Memory Safe Languages in Android 13

#148

Post by thesuperbigfrog »

netr0ute wrote: post #97
thesuperbigfrog wrote: post #26

Earlier quoted context omitted.

>> there's a ton of C++ code in the world that isn't going to be ported to Rust, and someone is going to have to fix all of those bugs in C++ code already in the wild. So you can get paid to be that person. That is well and good for legacy systems that cannot / will not be updated. Android is not a legacy system and is adopting Rust and seeing security benefits. Linux is not a legacy system and is slowly adopting Rus…

> Android is not a legacy system and is adopting Rust and seeing security benefits. > Linux is not a legacy system and is slowly adopting Rust and may see greater use with time. 100% USDA Grade-A Certified Prime BS, as shown by both projects' ages (15+, 30+ years) and maybe the definition of legacy. If you consider legacy to be something you have to keep a certain way so that it functions a certain way, then both are…

>> 100% USDA Grade-A Certified Prime BS, as shown by both projects' ages (15+, 30+ years) and maybe the definition of legacy

How should 'legacy' be defined?

If the software is actively developed and gets new features regularly, I would not consider it legacy.

If the software only gets maintenance / bug fix updates or is not updated, but is still used in production, then it is legacy software.

>> I would say projects like Fuchsia and Rust itself aren't legacy because you can move fast and break things

Fuchsia is not widely used (yet?). I am not sure how much "moving fast and breaking things" happens in Fuchsia.

Rust has the concept of editions (https://doc.rust-lang.org/edition-guide/editions/index.html) and spends significant effort to maintain backward compatibility.

You do not have to "move fast and break things" to not be legacy.

Re: Memory Safe Languages in Android 13

#149

Post by bluGill »

mk89 wrote: post #145
IshKebab wrote: post #132

Earlier quoted context omitted.

Did you read this bit? > It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement. They found ~100 security issues in 45k packages. That's clearly better than C++.

I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware…

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.

Re: Memory Safe Languages in Android 13

#150

Post by goodpoint »

kllrnohj wrote: post #147
goodpoint wrote: post #37

Earlier quoted context omitted.

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

I can't speak to the others, but Java & Kotlin do not at all have C++-like performance, especially not in anything beyond a toy level benchmark. And even in those toy level benchmarks (like https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ), there's a clear divide between C/C++/Rust & everything else.

The claim that performance are comparable only on "toy benchmarks" is false. Additionally, most of such simple benchmarks are not representative for real-life workload, and anyways the initial point was about safety.

Anyhow the whole HN conversation is now a trainwreck where any dissenting opinion is downvoted so there's no point to continue.

Post reply on HN