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

201–210 of 430 posts

Re: Rust in Android: move fast and fix things

#201

Post by tialaramex »

IncreasePosts wrote: post #184
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).

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that…

This idea that if Rust doesn't have all those memory safety bugs it must somehow have loads of other bugs we haven't discovered reminds me of Americans insisting that countries which don't have their lousy gun safety problems must have the same effects by some other means they haven't detected - Like, OK England doesn't have lots of gun murders like America, but surely loads of English people are just dropping dead because someone threw a yoghurt at them, or used harsh language, and we just missed them off our statistics ?

No man, it is possible to just do better, and this is an example of just doing better. The Rust is just better software. We can and should learn from this sort of thing, not insist that better is impossible and the evidence suggesting otherwise must be a mirage.

Re: Rust in Android: move fast and fix things

#202

Post by nine_k »

linkage wrote: post #156
spockz wrote: post #153

Earlier quoted context omitted.

Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownersh…

This assumes a perfect student who is not going to make any mistakes while writing their code, not even a typo. If an error is introduced, things become much harder on the C side. The compiler may miss it. It could manifest as a bug that only occurs in certain non-obvious circumstances, and manifests erratically (e.g. an out-of-bounds write clobbering data of a node next to it in the heap). Rust would most likely just not allow such a bug to be introduced.

In the same vein, driving on a modern busy road requires you to know about lanes, speed limits, various signs, traffic lights, rules of turning and merging, etc, etc. A road without all of that, where a steering wheel plus two pedals suffice, of course still allows you to drive, and drive fast, but it requires much more attention from a driver; many driver's mistakes are noticed later, and lead to more dangerous accidents.

Re: Rust in Android: move fast and fix things

#203

Post by tubthumper8 »

linkage wrote: post #166
kibwen wrote: post #157

Earlier quoted context omitted.

> Because it's not a silver bullet. It does look like a silver bullet, actually. In the context of software engineering, "silver bullet" inevitably leads to Fred Brooks: '"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or manag…

[flagged]

Who said that anyone is absolved of the responsibility to write tests for business logic when using Rust? I struggle to see anything in the comment you replied to that is anywhere close to claiming this

Re: Rust in Android: move fast and fix things

#204

Post by rascul »

tuetuopay wrote: post #177
guywithahat wrote: post #89

Earlier quoted context omitted.

Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.

How is Go memory safe? Memory safety does not mean "leaking memory". It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way. I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bound…

Rust doesn't consider leaking memory to be unsafe.

Re: Rust in Android: move fast and fix things

#205

Post by woodruffw »

linkage wrote: post #156
spockz wrote: post #153

Earlier quoted context omitted.

Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownersh…

How often do you find yourself implementing self-balancing trees in either C or Rust?

Re: Rust in Android: move fast and fix things

#206

Post by dinkelberg »

kccqzy wrote: post #196
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).

An earlier Google blog post from the same series (link in the first sentence) pointed out why: new code tend to have more vulnerabilities than established code. So it makes more sense to write new code in Rust than to rewrite old code in Rust. After all new features are still being added and new code needs to be written; it’s not like the codebase is done with features.

According to that blog post (https://security.googleblog.com/2024/09/eliminating-memory-s...), the vulnerability density for 5 year old code in Android is 7.4x lower than for new code. If Rust has a 5000 times lower vulnerability density, and if you imagine that 7.4x reduction to repeat itself every 5 years, you would have to "wait" (work on the code) for... about 21 years to get down to the same vulnerability density as new Rust code has. 21 years ago was 2004. Android (2008) didn't even exist yet.

Re: Rust in Android: move fast and fix things

#207

Post by gpm »

tuetuopay wrote: post #177
guywithahat wrote: post #89

Earlier quoted context omitted.

Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.

How is Go memory safe? Memory safety does not mean "leaking memory". It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way. I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bound…

> It's absolutely possible to bork ownership and have multiple thread trample a struct.

This is specifically the one place where go is not memory safe IMO.

> It's absolutely possible to compute wrong pointer offsets.

In Go? Without the `unsafe` package (at which point you are explicitly opting out)? How? There's no pointer offset in the first place.

> It's absolutely possible to dereference nil.

Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.

It's (really the lack of non-nil types) is one of many reasons why go doesn't produce as reliable software as rust, but it's not a memory safety issue.

> It's absolutely possible to reinterpret memory the wrong way.

Again, without the unsafe package? How?

Re: Rust in Android: move fast and fix things

#208

Post by array_key_first »

IncreasePosts wrote: post #184
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).

Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that…

The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.

C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code.

I mean, just the pretense that simple tool = simple engineering isn't necessarily true. Building a home using an excavator and drills is fairly straight forward. You know what's complicated? Trying to build a home using only a screwdriver. Yeah. Good luck with that, you're gonna have to come up with some truly insane processes to make that work. Despite a screwdriver being so much more simple than an excavator.

Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.

C++ and Rust? Easy. Templates and generics. C? Up until a few years ago, your options were: 1. copy and paste (awful) or 2. use void * (also awful).

Copy and paste means your implementations will diverge and you just artificially multiplied your maintenance burden and complexity. And void pointer completely throws away any semblance of type safety, forces you to write stupid code that's way more complex than it needs to be, and, to top it off, is horrible for performance!

That's just one example, but there's so, so many when you look around C++ or Rust enough. And these are not rare things, to me. To me, these are everyday coding problems.

Anonymous functions? There's another one. Encapsulation? Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.

Re: Rust in Android: move fast and fix things

#209

Post by samdoesnothing »

kibwen wrote: post #163
samdoesnothing wrote: post #155

Earlier quoted context omitted.

They found a memory safety bug in their Rust code and assumed it was the only memory safety bug in their Rust codebase. And then they compared it to the historical average in C++ code that's been around for almost two decades in production. I can't be the only one here who sees how biased this comparison is right?

Rather, they found one memory safety bug in their Rust codebase, and measured it against the legions of memory safety bugs they found in their C++ codebase. In neither case are they measuring against bugs not found, so no, it's not biased.

Except it's not an apples-to-apples comparison. The C++ code has been around a lot longer, and a lot of it was written with older versions of C++ which didn't have modern safety features. I'm sure there is a bunch of new/delete in their codebase still. And I'm sure they're actively looking for memory safety issues in C++, and probably not so hard (if at all) with Rust.

Re: Rust in Android: move fast and fix things

#210

Post by samdoesnothing »

josephg wrote: post #144
mk89 wrote: post #30

Earlier quoted context omitted.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

> I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all th…

It's not about learning syntax, it's about finding it generally tolerable to read. I personally find Rust syntax repulsive and would opt for a different language unless Rust was literally the only option. Thankfully it's never the only option, now or in the future.
Post reply on HN