Rust in Android: move fast and fix things
Posted by ViewTrick1002@reddit | programming | View on Reddit | 100 comments
Posted by ViewTrick1002@reddit | programming | View on Reddit | 100 comments
vinzalf@reddit
Cult of Rust strikes again
stylist-trend@reddit
Sometimes I wonder if entities are trying to shit on Rust because they benefit from software having more vulns. Otherwise oh my god, this ragebait is so low effort.
vinzalf@reddit
I'd argue that most, if not all ragebait, is low effort. It's a trend I'm pointing out, though. Rust is on the hype train right now, and as far as I can tell it doesnt live up to the hype.
The article presents several interesting points, but hardly a conclusive analysis. Especially considering the recent and ongoing Ubuntu/Rust Coreutils issues.
NYPuppy@reddit
Rust is already widely deployed. I guarantee you that you're using Rust code repeatedly throughout the day without noticing, that's how widespread is.
In other words, you and your cult of bad engineering already lost your fight.
It's funny that you discount the article which talks about years of rust use at Google solving real problems, but you point to uutils which had a few minor regressions. I mean lol you must really be deep in your cult for that kind of doublethink, right?
stylist-trend@reddit
The trouble is the anti-Rust people complaining that things written in Rust still have bugs, which is not something anyone was claiming wouldn't happen. On top of that, most of the coreutils issues have been things like "the developer didn't implement a flag". How do you expect a programming language to fix that?!
But point of evidence after point of evidence is repeatedly coming out from all angles (Google, Microsoft, Linux) that memory vulnerabilities specifically are significantly reduced. Including the post you're commenting on.
Something that "Cult of Rust strikes again" addresses none of. How does that point out a trend?
vinzalf@reddit
Bro I get it, you love rust. It's really just another lang, though. These issues, in either rust or C/C++, are skill issues and probably come down to the competancy of the teams themselves.
EveryQuantityEver@reddit
Fuck all the way off with the “git gud” argument. There is not a logical reason to reject tools that make it harder to write bugs.
stylist-trend@reddit
Rust is great, and has real, actual benefits over C, yes. I don't "love it" per se, but yes, it is just another language (which is why I'm astounded that it's generated this handful of people frothing at the mouth to hate it).
If you think the best developers in the world have "skill issues" that suddenly disappear literally a thousandfold when using a different language, wake up lol.
And on that note, who cares anyway? Programming is about building working things (and having fun if it's a hobby), not narcissistically jerking yourself off about how amazing of a programmer you are, at the expense of exploits caused by memory vulnerabilities.
Full-Spectral@reddit
The classic 'git gud' argument. There are so many folks like him. There's a guy over in the C++ section arguing endlessly against other C++ people that C++ is completely memory safe and if not then it's a skill issue.
1668553684@reddit
Some of this is also culture. You have Rust devs putting out level 10 CVEs and urgent patch notices for bugs that a C++ developer would just mark WONTFIX and move on from.
Seriously, read some CVEs from Rust projects.
ViewTrick1002@reddit (OP)
Is a 5000x improvement reducing the number of memory vulnerabilities in one of the most high profile projects on earth a cult?
vinzalf@reddit
Ask canonical how that's working out for them lately
ViewTrick1002@reddit (OP)
So you mean that the good old sudo never has any CVEs? Maybe check the security advisories?
https://www.sudo.ws/security/advisories/
We quickly find privilege escalations and memory vulnerabilities. Way worse issues than what was found for sudo-rs.
The sudo-rs advisory is for:
https://ubuntu.com/security/notices/USN-7867-1
When running the regular Ubuntu branch. The entire point is to get coreutils ready for primetime when the next LTS ships.
stylist-trend@reddit
I like how he just suddenly stopped replying.
Amazing-Mirror-3076@reddit
Rust is the right choice here, it's when people start writing webapps in rust that I roll my eyes.
WillGibsFan@reddit
Sure but this has nothing to do with the rewrite in itself. You should blame the ubuntu maintainers.
morglod@reddit
Rust cult already get reality check with sudo-rs. Thanks for security, but it is exactly the opposite.
BerkeDemirel@reddit
Well, the bug in sudo-rs was a logic bug, not a memory one so I guess it's working as intended.
morglod@reddit
Replacing 45 years tested working software with 1 year crap that barely pass existing tests is security issue as it is.
WillGibsFan@reddit
Sudo isn‘t done mate. You‘re making it sound as if it was written and tested and finished for that timeframe, which it isn‘t.
morglod@reddit
Yes. That's exactly what I'm talking about. Don't you think that pushing to production, "not finished and not tested" thing is bad for security?
gmes78@reddit
You mean the same software that had a couple of CVEs this year?
morglod@reddit
As any software. How it's related to anything? You want to compare speed of CVEs appearance? Rust is faster here. You want to say that rust has no CVEs? No, it's already false.
gmes78@reddit
Your dear "45 years tested working software" still struggles with bugs, how is it any better?
morglod@reddit
Where are guarantees that there are no repeated bugs, or no new bug introduced by rewrite, because rust has some limitations due to borrowing mechanisms? Ah it already has it! Basic logic goes out of scope here. The only bugs that are "fewer potential", are SOME memory issues that could be inside sudo's source and not in unsafe sections. I'm sure it was not there with previous version too.
gmes78@reddit
You write tests...
You just gave away that you don't understand how Rust works at all. The borrow checker doesn't induce you to make mistakes, any more than any other language difference would.
???
No shit. That's the point. Stop downplaying bad memory-related vulnerabilities are.
Also, Rust also prevents many logic bugs, due to its strong type system.
???
morglod@reddit
Tests should include all previous CVEs and cases of original code. When it's not fully compatible, it could not pass it.
Limitations due borrowing forces to write different code which leads to untested code which leads to more unknown CVEs.
My initial argument was about replacing existing tested software with untested. If you don't want to throw words, well don't throw it. Ahahah
gmes78@reddit
Good thing that the sudo-rs devs have looked at every single sudo CVE and checked their code against them.
Do you think the developers are idiots? Because it looks like you do.
Wow, if you rewrite code, you end up with different code. Who could've guessed?
morglod@reddit
I'm glad you finally understood
WillGibsFan@reddit
BS. The rewrite actually found more sec vulns in the original than they included in their own rewrite.
ViewTrick1002@reddit (OP)
So you mean that the good old sudo never has any CVEs? Maybe check the security advisories?
https://www.sudo.ws/security/advisories/
We quickly find privilege escalations and memory vulnerbalities.
The Rust advisory is for:
https://ubuntu.com/security/notices/USN-7867-1
When running the regular Ubuntu branch. The entire point is to get coreutils ready for primetime when the next LTS ships.
morglod@reddit
You swapped the facts and then tried to find counter arguments for it. No, I didn't mean that.
Changing any software that has been cleaned for 45 years out of vulnerabilities and different cases, to software that barely passes a few unit tests IS a very big security issue. Only if it was formally verified, than it's good idea.
cecil721@reddit
Seems like a good time to learn Rust.
CaptainMania@reddit
Swift on android seems more plausible
KawaiiNeko-@reddit
Joke of the year
hgs3@reddit
I think it would be more telling if Google reported how many panics made it to production in the Rust code. What would be a memory bug in C++ corresponds to a panic in Rust. If both implementations are written at compatible quality levels then I’d expect the rate of panics vs memory bugs to be comparable.
ViewTrick1002@reddit (OP)
Those are simply astounding stats. Both preventing vulnerabilities, preventing logic bugs and shipping faster.
Ameisen@reddit
How does one determine "memory safety vulnerability density"?
I assume that they're using a static analyzer, but in that case... why not fix the vulnerability that has been detected before you rewrite it? Why keep the vulnerability around until you've completely rewritten it?
Graumm@reddit
It depends on how it’s measured, but it’s still a win for Rust regardless of how it measured.
Static analysis for memory issues generally happens in a CI build, and they can be slow or unreliable if a piece of code is not fully exercised. Rust is still an improvement in this respect because the code doesn’t compile, which means it does not leave the dev local machine, and the feedback loop is smaller.
If this is measured by some association of post-release vulnerabilities to the offending code/codebase, then it’s just a pure win. The issues don’t get released.
Ameisen@reddit
The fact that there are persistent issues that go down over time as it is rewritten suggest to me that they are existing and present issues.
My point, though, is that they've clearly detected these problems already to have these statistics, and rewriting in Rust or anything else takes time - evidenced by the fact that vulnerabilities persist for years.
I'd fix the vulnerabilities that are known immediately so that they aren't a potential problem until you get around to rewriting in Rust or such.
I am not arguing about Rust or whether it's a "win" for it, but rather why these vulnerabilities aren't fixed prior to a Rust rewrite which can take an arbitrary amount of time. You must already know of the vulnerabilities to actually generate these statistics.
Graumm@reddit
I’m sure they are fixing these issues in their existing code. They don’t seem to be talking about any specific codebase in the article, as much as that they are comparing vulnerabilities reported over time between their supported languages in general. Specifically they mention that they are producing as much net new rust code as they are C++ code, and so they have a good sample size to compare the languages.
They will almost certainly use this analysis to justify choosing Rust over C/C++ for new projects and security sensitive rewrites. This data does tip conversations into rewrite territory if it really is catching issues before they ship, and making their dev teams faster because their time is not wasted on operational support.
Ameisen@reddit
People get mad if you don't mark that you've edited it, and people get mad when you do mark that you've edited it :/
Graumm@reddit
I upvoted you! almost back to net zero
StemEquality@reddit
"The results agree with my biases so I will blindly trust the methodology."
At least you're honest about it I suppose.
Graumm@reddit
If we can’t trust google make remarks about code quality at scale with 5 million lines of Rust then who?
I would say it matches my experience with Rust, rather than my bias. It makes you think about projects in a particular way, and I have had a similar lack of issues compared with other languages. So perhaps:
“The results disagree with my biases so I will idly whine about Rust.”
Please be more honest with your biases
angelicosphosphoros@reddit
It is probably amount of defects detected during testing.
Ameisen@reddit
Then why aren't they fixing those defects immediately so that they don't persist until they get around to rewriting it in Rust?
It seems bizarre that those defects persist for years despite being known.
ViewTrick1002@reddit (OP)
They get fixed? The count is how many they have to fix or manage after the PR is shipped.
Ameisen@reddit
I was under the impression that it was net vulnerabilities in the project, not vulnerabilities in mew/modified code.
angelicosphosphoros@reddit
It is more detection rate. It is possible for a bug to exist but not be discovered until later. So read this as "new bugs discovered".
mr_birkenblatt@reddit
They computer that by number of vulnerabilities per million lines of code. It's in the article
Revolutionary_Ad7262@reddit
In the past they published some statistics about it. Most of the vulnerabilities are detected in a exponential decay way (the obvious one are detected fast, where those more obscure later on).
So I guess just compare the trend in C++ and Rust code
james7132@reddit
AFAICT, it's a number of reported vulnerabilities against the number of changed lines of code. I guess it could be gamed by making your security contact inaccessible or just not making changes to your code, but I don't know why Google would try to game those metrics.
Ameisen@reddit
For me, it's just bizarre that the vulnerabilities drop linearly with the amount of memory-unsafe code. That implies that they are neglecting them until they get around to rewriting the entire module, which can take an arbitrary amount of time.
Unless you mean that it's the number of detected vulnerabilities in new/modified code.
james7132@reddit
It's mentioned in the article and chart, new/modified code is exactly what they're talking about.
Ameisen@reddit
Ah, I must have missed it.
That is an insane number of new vulnerabities, though. Their C++ must be... strange.
lelanthran@reddit
So, for every 1000 memory safety bugs they had per $X lines of C++ code, they have only 1 in $X lines of Rust code?
Yeah, I'm calling bullshit.
wrongerontheinternet@reddit
The pervasiveness of these kinds of bugs in C++ code is literally the reason that Rust exists. 1/1000 lines (their observed rate of memory safety bugs in C++ code) is not a particularly high rate--99.9% of the time, C++ programmers avoid these issues. The problem is that every single one of those bugs can potentially undermine the entire process, so 99.9% is nowhere near good enough. We need something more like 99.9999%, which is where Rust comes in.
ViewTrick1002@reddit (OP)
That is detailed in the article. They have shipped 5 million lines of Rust in the Android codebase.
In all those lines of Rust they have shipped one memory vulnerability, which was caught before it went live due to tooling on for example the Pixel line of phones.
Comparatively for C and C++ their run rate is 1 memory vulnerability per 1000 lines of code. Or as they put it, 1000 bulbs per 1 MLOC.
Graumm@reddit
On principle I usually consider lines-of-code comparisons to be bullshit, but the difference in vulnerabilities is so staggering here that it doesn’t even matter
vytah@reddit
Rust usually takes fewer lines of code than C++ to do the same thing, but not thousands times fewer.
Unlucky_Journalist82@reddit
1000x reduction. How bad was the original spurce code?. I cannot imagine a software with that many memory issues. Either BS or the original code was just terrible?
Not much of a win if old code was poorly written.
ViewTrick1002@reddit (OP)
It is the Android open source codebase? Given the threat surface and fallout from vulnerabilities doubling think it’s badely written?
Unlucky_Journalist82@reddit
It can be any codebase. 1 memory issue/ 1k lines is bad. I have worked with larger codebases and we had 1/ 3k -4k lines. And that was a poorly written code which initially written in late 90s.
masklinn@reddit
Given 1 issue per thousand lines is considered really good (outside of critical software) and from previous stats memory safety issues tend to be 70~75% of defects in unsafe languages, it seems a lot better than average.
Sure jan.
1668553684@reddit
Was it tested and scrutinized anywhere near as well as Android is? If no, then you have no idea how many memory vulnerabilities you had, all you know is that you caught 1 per 3ksloc. If I unleashed a team of the finest security researchers in the world and gave them a Google budget, are you sure they wouldn't find more?
Also, was it doing the same kind of work Android is? If you're talking about a CRUD app, you can see how that would be easier to get right than what is essentially an operating system.
gmes78@reddit
That you found.
Android is, very likely, significantly more looked at and tested than whatever you have worked on, so issues are found much more quickly.
jonas_h@reddit
It also matters what kind of code you're writing. I imagine Android is lower level than many other projects.
ViewTrick1002@reddit (OP)
New code or existing code? Last year they went into a deep dive on how old code with a lifetime of bugfixes applied is pretty safe - if left untouched.
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
1668553684@reddit
It's Android. It's a gigantic project.
mediocrobot@reddit
Highly skilled Google engineers, the cream of the crop, are too noob-ish to write good C++ code? I'd imagine the memory safety problem is worse for average engineers.
Minimonium@reddit
While not taking away from this research, your statement is kinda funny with respect to what Rob Pike said about Googlers and why Go exists. :)
bik1230@reddit
And yet, to this day, Go is only used by a small minority of the teams at Google, and C++ has remained the primary language for almost all development until just recently with the move to Rust.
asmx85@reddit
This is just a perspective problem. "I don't know about any problems in the software i/my company writes that barely anyone uses and nobody tries to attack compared to what is happening at companies of the likes of google." So the amount of vulnerabilities in "ordinary" software is never revealed does not mean it does not exist. But people will make that assumption. A highly looked at codebase from the best professional programmers out there is of course sub par the random stuff i/my company writes because we never deal with any of this kind of problems. I am really cool – QED.
vytah@reddit
I wonder what would happen if a bunch of security researchers and security enthusiasts all swarmed upon a random medium-size, relatively popular, yet essentially unimportant C or C++ project, and looked for vulnerabilities in it for a while.
SoilMassive6850@reddit
At work where I was mostly writing Python before (though not by choice) and recently moved towards rust for new projects I kind of have to agree that it is quite easy to write working code. But that's because Python is a special kind of hell for more complex code.
I haven't written much C++ in my professional life, but in my personal and hobby experience the big difference in why rust code tends to just work compared to it is how ubiquitous things like using Enum, Result and Option types are compared to C++'s optional, variant and expected. Due to that together with its pattern matching functionality it's often very easy to write rust code that comprehensively handles all cases, unlike in C++ where libraries handle return types, errors and such is inconsistently at best due to their age, and will likely never become consistent.
Obviously those things aren't solely a property of rust, but it is in my opinion what makes it easier and faster than C++ (or Python), especially as the compiler gets in the way when people get silly ideas in terms of how to quickly hack something together with side effects etc. which I saw a lot in C++.
jonatansan@reddit
Yeah, as a C++ professional dev, I agree with you. C++ doesn’t lack tools for safety, but it doesn’t enforce them either. The effort to use them must come directly from the devs, and each projets/teams will enforce different subset of those tools, whereas in Rust you just won’t be able to compile nor ship your code if you don’t use those tools.
JShelbyJ@reddit
Agree. It enforces a mental framework for me so I can know with certainty that everything is correct. With python I have to think through everything on my own.
syklemil@reddit
There's no compilation step for Python, but there are typecheckers and linters that can catch a lot of the trivial stuff.
Unfortunately for us that like to run stuff in strict mode, a lot of Python libraries, even the big, well-known ones, have awful type stubs, or even require jumping through some hoop to get type stubs at all.
When my options are
# type: ignorethen I don't want to use Python for that problem any more.
JShelbyJ@reddit
My journey to rust started when I realized the level of effort required to make python usable was greater than the effort required to learn rust.
And not just type checkers and linters. The same applies for other aspects of python as well.
syklemil@reddit
I just wrote the same thing to the other commenter here as well.
These days I use
export FOO=BARorfoo --bar=bazAmazing-Mirror-3076@reddit
Like c++ it's time we moved on from python. Rust is probably not the right answer if you are coding in Python now.
syklemil@reddit
Rust/Python interop is pretty good though, with tooling like maturin/PyO3.
Likely a lot of Python code is also stuff that can actually be written in Rust, as there seems to be a good amount of people who are pretty comfortable moving in that direction. My first Rust program was actually a replacement for a relatively simple but wonky kubernetes-controller like thing in Python that would intermittently just silently stop processing data, after watching a talk on writing controllers in Rust. The Rust version just … worked. And it was a lot simpler to pick up Rust and get it working than The Internet™ had led me to believe.
ward2k@reddit
I'd like Python a lot more if the tooling wasn't so dogshit
Asking someone "hey which package/environment manager should I use" and being sent 50 different ones with everyone arguing in the comments is so exhausting
pacific_plywood@reddit
It’s just uv now
But, yknow, the fun part is knowing that the answer could change in a couple years!
ward2k@reddit
Oh yeah I know, I use UV myself whenever I'm doing python projects
Doesn't change how bad the tooling is still for me
def-pri-pub@reddit
What is the ratio of C/C++ code to Rust code in the Android project? My assumption is that there is more C/C++.
When I look at something like the rollback statistic (which does favor Rust), I have some qualms because the C/C++ sections are probably dealing with a lot more legacy than the Rust code; so it's natural there would be more rollbacks with C/C++.
matthieum@reddit
That's a good point.
To be more specific, I'd imagine that Rust code is not deeply intertwined with C/C++ code, which would mean:
syklemil@reddit
I can't help but get the feeling that Chromium is oxidizing faster than Firefox, even though Rust started at Mozilla.
Firepal64@reddit
Chrome refuses to support JPEG XL even though it was co-developed at Google...
1668553684@reddit
Apple was a major force behind designing the USB-C spec, but it took the EU passing legislation to force them to use it for their phones.
caspy7@reddit
[Funny to be back on topic again, but] Google Research has rewritten the JPEG XL decoder in Rust for Mozilla who is now landing it in Firefox. This and other pressures (e.g. increasing adoption, the PDF thing) may very well have them change course.
Frexxia@reddit
They'll be forced to bite the bullet when PDF introduces JPEG XL in the next standard
soft-wear@reddit
Mozilla’s annual revenue is a rounding error relative to Google, which conveniently for this comparison is the one that pays most of it.
syklemil@reddit
Yes, I know. But Mozilla also could've had the biggest possible head start on both training people in Rust and figuring out some strategy that works for them. Their blog post on Stylo is nearing 10 years old. The productivity gains Google are talking about probably would go a long way in outfits that don't have Google's resources.
Instead they seem to have laid off the entire Servo team, and then … I don't know.
bik1230@reddit
I remember reading something from a Gecko engineer years ago regarding Rust and Servo. It took years to properly integrate Servo code, in part because they needed to make Gecko more modular, and in part because Servo wasn't nearly as compatible with the web as Gecko.
So after Gecko became modular enough, the Gecko team started just doing their own new Rust development without involving Servo, because it was much easier that way. So there's a decent amount of Rust work going on, even if they maybe don't have enough engineers to wholesale replace lots of old C++ code.
enbacode@reddit
What’s meant by the Rule of 2 here? I couldn‘t find anything on Google that would make sense in this context.
dkxp@reddit
From: https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
The Rule Of 2 is: Pick no more than 2 of
vinzalf@reddit
Bro I get it, you love rust. It's really just another lang, though. These issues, in either rust or C/C++, are skill issues and probably come down to the competancy of the teams themselves.
BlueGoliath@reddit
Year of Rust on Android?