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

81–90 of 606 posts

Re: Memory Safe Languages in Android 13

#81

Post by Octokiddie »

> 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 the incremental addition of Rust work in practice? What strategies and tools come in handy? Also, what are some good case studies where Rust was introduced to add new features, but still needed to work within a system mainly composed of C/C++? I've seen some of the first steps with Linux, but I'm thinking of a project where more substantial additions have been made.

Re: Memory Safe Languages in Android 13

#82

Post by LAC-Tech »

Mesopropithecus wrote: post #75
pornel wrote: post #62

Earlier quoted context omitted.

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…

> Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. That was my concern that I had when I started learning the language. I think it is true, but I was surprised how quickly I managed to get used to the Rust way.

I'm surprised at how slowly I'm getting used to it!

I mean I've improved but I still have a lot of "wtf" moments. End up doing a lot of deep copying and heap allocations just to shut the compiler up, which makes me question just how "zero cost" the safety is.

Re: Memory Safe Languages in Android 13

#83

Post by selfmodruntime »

estebank wrote: post #49
stonemetal12 wrote: post #39

Earlier quoted context omitted.

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

>Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language

I'm still thinking about how we could integrate something like that in a language or the languages package manager. I'm unsure if it's possible.

Re: Memory Safe Languages in Android 13

#84

Post by Ar-Curunir »

selfmodruntime wrote: post #79
dist1ll wrote: post #69

Earlier quoted context omitted.

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…

I love Rust, but I kind of believe in the conspiracy that comptime code features are less loved by the Rust language maintainers because they increase compile time even more.

That directly contradicts in-progress efforts to make `const` better. Things like `const trait`, `const Allocators`, etc are all in progress.

Re: Memory Safe Languages in Android 13

#85

Post by burntsushi »

dahfizz wrote: post #77
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…

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 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 by std without using any `unsafe` explicitly whatsoever.

And it is not at all uncommon to write application code in Rust that doesn't utter `unsafe` at all. Even ripgrep has almost none of it. At the "application" level it has exactly two uses: one related to PCRE2 shenanigans and one related to the use of file backed memory maps. Both of those things are optional.

Then there's another whole perspective here, which is that if you're using Rust in the first place, there's a non-trivial chance you're working on something "low level" that might require `unsafe`. Where as with Python you probably aren't doing "low level" work and just don't care much about perf within certain contexts. That has less (albeit not "nothing") to do with the design of the languages and more to do with the problems you're trying to solve.

To be clear, I am not saying you're definitely wrong. But as someone who has written many tens of thousands of lines of both Rust and Python, I would put them on the same or very very close level in terms of memory safety personally. Certainly within the same tier.

Re: Memory Safe Languages in Android 13

#86

Post by estebank »

selfmodruntime wrote: post #79
dist1ll wrote: post #69

Earlier quoted context omitted.

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…

I love Rust, but I kind of believe in the conspiracy that comptime code features are less loved by the Rust language maintainers because they increase compile time even more.

This isn't the case, it's just that the approach to bring comp time evaluation to Rust is difficult because we're trying to side step potential back compat or ambiguous restrictions that we otherwise would have. Rust follows the "when it's ready" delivery approach wich means that some eagerly awaited features take much longer than us, as users, would want.

Re: Memory Safe Languages in Android 13

#87

Post by bmicraft »

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…

It really sounds like you didn't read the article at all. It explicitly mentions Java/Kotlin in one breath with rust almost any chance it gets.

Re: Memory Safe Languages in Android 13

#88

Post by netr0ute »

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…

I had the same experience with Rust too. After trying and failing for hours to trudge through syntax BS, I'm (probably) not touching it again until something big changes. I can't even get user input without making a huge ugly one-liner or importing some dependency.

Re: Memory Safe Languages in Android 13

#89

Post by thesuperbigfrog »

burntsushi wrote: post #65
pclmulqdq wrote: post #56

Earlier quoted context omitted.

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.

Ada has "unchecked" operations:

Unchecked Access (unsafe pointers): http://www.ada-auth.org/standards/22rm/html/RM-13-10.html#I5...

Unchecked Deallocations ("free"): http://www.ada-auth.org/standards/22rm/html/RM-13-11-2.html#...

Unchecked type conversions (unsafe casting): http://www.ada-auth.org/standards/22rm/html/RM-13-9.html#I57...

Ada has FFI:

C / C++: http://www.ada-auth.org/standards/22rm/html/RM-B-3.html

COBOL: http://www.ada-auth.org/standards/22rm/html/RM-B-4.html

Fortran: http://www.ada-auth.org/standards/22rm/html/RM-B-5.html

Ada has pragmas to both enable more security measures or relax security measures:

http://www.ada-auth.org/standards/22rm/html/RM-L.html

Just like in unsafe Rust, sometimes in Ada you need to turn off some security features or tell the compiler "I know what I am doing for this part" when interfacing with some hardware or similar low-level stuff.

Re: Memory Safe Languages in Android 13

#90

Post by Ar-Curunir »

dahfizz wrote: post #77
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…

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.

One could implement many data structures without unsafe, but with less efficiency. E.g. using an arena allocator
Post reply on HN