Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in Android: move fast and fix things

security.googleblog.com

Post reply on HN
Print view View original

371–380 of 430 posts

Re: Rust in Android: move fast and fix things

#371

Post by ActorNightly »

ikety wrote: post #112
ActorNightly wrote: post #88

Earlier quoted context omitted.

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…

I'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it. Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design…

> because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it.

This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you)

While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this.

Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.

Re: Rust in Android: move fast and fix things

#372

Post by AlotOfReading »

tialaramex wrote: post #344
jkrejcha wrote: post #323

Earlier quoted context omitted.

> What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all. This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1]. Conforming programs do not have this requirement an…

The C++ ISO document describes conforming implementations of their language, ie compilers and similar tools - that conformance isn't a property of your program at all. So far as I can tell there is no mention of the program conformance you're describing.

There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. In theory you could have an implementation that gives semantics to UB like Fil-C or CCured do. No mainstream implementation does that for memory unsafety due to the performance overhead, and conforming implementations are required to document those extensions. I don't think there's a sane argument for an implementation to intentionally choose the behavior in the example I provided and Clang certainly doesn't, so it's non-conformant regardless.

Re: Rust in Android: move fast and fix things

#373

Post by sniggler »

stocksinsmocks wrote: post #61
delusional wrote: post #35

I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both. Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code writt…

I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.

[dead]

Re: Rust in Android: move fast and fix things

#375

Post by arw0n »

tiltowait wrote: post #234
pityJuke wrote: post #120

Earlier quoted context omitted.

There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it. And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).

People are worried about half-assed[0] rewrites that break functionality and introduce exciting, new vulnerabilities due to improper implementation. And they aren't wrong to fear that, given the multiple issues we've seen in just the past week with Ubuntu's Rust overhaul. [0]: Or even whole-assed. Memory (un)safety is only one form of vulnerability.

They were half-assed in the sense that they trusted the old test suite, which turned out to be a mistake, as some edge-cases weren't covered. Hopefully they will be more rigorous going forward, but even then, these bugs were caught before being added to a stable release, so overall fine.

I'm not sure if it is the best ROI to rewrite battle-tested tools in Rust, but it isn't like people are forced to do it. People have fun writing Rust, and want to work with it more, so that's the direction these projects take. And if you don't want to use these tools, the beautiful thing about Linux is that if you don't like the direction a distribution takes, you can always switch.

Re: Rust in Android: move fast and fix things

#376

Post by AlotOfReading »

ActorNightly wrote: post #364
AlotOfReading wrote: post #135

Earlier quoted context omitted.

There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. This is effectively true in C and C++ though. Show me a nontrivial project in either of those languages that has never had a memory safety issue and I'll show you a project that doesn't look at quality. Even SQlite doesn't meet this bar, despite incredibly skilled programmers and an…

>Show me a nontrivial project in either of those languages that has never had a memory safety issue I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.

There's been over a thousand memory safety CVEs in the kernel this year alone [0], the most recent published 2 days ago. Most of these aren't exploitable and are caught before stable, so I went to LWN instead and "scrolled down" until I saw an article that mentioned a memory safety vuln in stable kernels. "Scrolled down" is in quotes because there was no scrolling involved. Today's Friday security updates post links USN-7861-3 [1], which includes fixes for memory safety issues like CVE-2025-37838 [2].

[0] https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...

[1] https://lwn.net/Articles/1046495/

[2] https://nvd.nist.gov/vuln/detail/CVE-2025-37838

Re: Rust in Android: move fast and fix things

#377

Post by arw0n »

josephg wrote: post #170
dgacmu wrote: post #159

Earlier quoted context omitted.

Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then…

My favorite framing for this is that rust front loads all the pain. C and C++ are incredibly subtle languages. But you can get a lot of code written before you run into certain foot guns in C and C++. This gives those language a more enjoyable on-ramp for beginners. In comparison, rust is a wall. The compiler just won’t compile your code at all if you do anything wrong. This makes the act of learning rust much more p…

At least the Rust compiler gives pretty good advice on what is going wrong. And for complete beginners, agentic AI can soften the pain a lot if used correctly. By used correctly I mean the following work flow:

1) Design in correspondence with AI. Let it criticise your ideas, give you suggestions on tools/libraries/techniques, and have concepts and syntax explained to you. Stay aware that these models are sycophantic yes-machines.

2) Implement yourself.

3) Debug in collaboration with AI. If you ask a question like "I'm getting [error], what are the most likely reasons for this happening?", you can save a lot of time finding the issue. Just make sure to also research why it is happening and how to solve it independently.

4) Let AI criticise your final result and let it offer suggestions on what to improve. Judge these critically yourself.

There is some worth in spending hours trying to fix a bug you don't understand, it builds resilience, helps you get familiar with a lot of language topics, and you probably won't make the same mistake again. But the above approach is a pretty good compromise of letting AI help where it excels, while still keeping enough control to actually learn something yourself.

I believe that Rust is the language benefiting the most from agentic AI, because the compiler is such a strong gate-keeper, and the documentation of almost all aspects of the language is comprehensive and clear. The biggest pain points of Rust are also reduced by AI: Front-loaded learning curve is softened, refactoring is something gen AI is actually decent at, and long compile times can be spent productively by already planning out the next steps.

Re: Rust in Android: move fast and fix things

#378

Post by flohofwoe »

quotemstr wrote: post #359
flohofwoe wrote: post #291

Earlier quoted context omitted.

Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain. The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.

I've never understood why developers fixate on having "pure" NDK-based apps. It's really not that hard to implement Activity, Service, etc. as JVM in Kotlin or Java and call the native code via JNI. What do you think the "pure native" app layer in Android is doing if not that?

It's not about the idea of writing a pure native app, but about making it easier to build a hybrid app without an exploding build process complexity.

Emscripten is again a perfect example of how it should be done: FFI calls into Javascript are trivial (it's even possible to embed JS code into C/C++ source files), and I can build a complete hybrid WASM/JS app without having to bring in a completely different build system that's completely alien to the C/C++ world.

It even works without any build system at all since the emcc compiler/linker wrapper is also the Javascript bundler, yet the entire emcc wrapper acts like a GCC/Clang compatible compiler/linker with some extra Emscripten specific flags. The Emscripten SDK didn't jump into existance like this, the difference to the NDK team is that the Emscripten team actually listens to their users.

Re: Rust in Android: move fast and fix things

#379

Post by iknowstuff »

ActorNightly wrote: post #366
iknowstuff wrote: post #115

Earlier quoted context omitted.

> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues. lol. this take is hilarious in the face of the article you are commenting on. holy cognitive dissonance. > The downsides of Rust is that its ownership semantics are often cumbersome to write skill issue

>skill issue Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code. Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.

Readers, feast your eyes on direct evidence of how facts don’t change people’s minds. You can almost see him putting fingers in his ears and going lalala

Re: Rust in Android: move fast and fix things

#380

Post by IshKebab »

ActorNightly wrote: post #368
IshKebab wrote: post #143

Earlier quoted context omitted.

1. You don't know what you're doing - everyone makes mistakes. 2. You can still write bugs in Rust but the point is you are far less likely to.

>You don't know what you're doing - everyone makes mistakes. I mean if you don't know what you are doing you are going to make mistakes that go beyond memory safety. Look at Log4shell for example.

The important thing is the likelihood of mistakes getting past the compiler. According to Google's numbers the likelihood for memory safety reduces by several orders of magnitude, and the likelihood for other kinds of mistakes reduces by a factor of ~4 (depending on how you interpret their numbers).

Just saying "but you can still make mistakes" is dumb and irrelevant and it's kind of disappointing that it's such a commonly bandied non-argument that Google still had to address it in this post.

Post reply on HN