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

291–300 of 430 posts

Re: Rust in Android: move fast and fix things

#291

Post by flohofwoe »

quotemstr wrote: post #226
flohofwoe wrote: post #67

Earlier quoted context omitted.

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.

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.

Re: Rust in Android: move fast and fix things

#292

Post by justjulia »

array_key_first wrote: post #208
IncreasePosts wrote: post #184

Earlier quoted context omitted.

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

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

Do I?

I would simplify the problem to not need different types or generic operations.

Or if I really need generic operations, break them down to smaller operations so you don't need to take a bunch of type parameters everywhere.

For example containers, instead of having container, have the container operations return an index or 'opcode', then the user applies that to their data. The container doesn't need to know about T, void pointers or sizes, just its own internal bookkeeping stuff.

Re: Rust in Android: move fast and fix things

#293

Post by blub »

bgwalter wrote: post #181
habibur wrote: post #74

5 million Rust LOC One potential memory safety vulnerability found Rust is 0.2 vuln per 1 MLOC. Compared to C and C++ : 1,000 memory safety vulnerabilities per MLOC. Key take.

Further up they refer to Android C/C++ code, not C/C++ in general: "We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code." Which means they had a pretty poor code base. If they had spent more time on engineering and less time on features that are canceled after 12 months anyway, they could have written better C/C++.

I peruse Android system code at work and their C++ code base is not designed for safety. It’s just typical C++ code as any large company would write it.

And for a large juicy target like Android, that won’t be good enough to stay ahead of the attackers long term.

Of course, tools like Fil-C or hardware-based security might make Rust vs. C or C++ moot.

Edit: your comment makes a good point. Shame that trigger-happy (c)rustaceans are downvoting everything in sight which is not praising this PR piece disguised as a technical blogpost.

Re: Rust in Android: move fast and fix things

#294

Post by dminik »

themafia wrote: post #256
surajrmal wrote: post #229

Earlier quoted context omitted.

70% of bugs in a large mature c++ code base come from memory safety bugs. Yes it's not the only type of bug, but it sure is the majority. Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. Rust enums make it easier to associate state with specific states, option types actually force you to check if they are valid, result types force you to check for errors, etc. Any…

> 70% of bugs in a large mature c++ code base come from memory safety bugs. Are 100% of those exploitable? This single ended statistic is simply not useful. > Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. You have proof of this? > Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits. That's not how these measureme…

> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.

I'm not entirely sure where this idea even comes from. Why would it be desirable for a systems programming language to be sparse on features?

Re: Rust in Android: move fast and fix things

#295

Post by pjmlp »

apitman wrote: post #253
pjmlp wrote: post #5

Note that Google still doesn't have official support for using Rust in Android userspace, though. Despite all pluses on the blog, NDK only supports C and C++ tooling, same on Android Studio, and it is up to the community to do the needful work, if anyone feels like using Rust instead.

They've been trying to strangle the NDK for years. You can't even make an app without a ton of glue code on the JVM.

True, NDK was never intended to make apps, only for games and as helper for native methods, since it was introduced in Android 2.1.

The point is about the official support for using Rust exactly for the same use cases.

Re: Rust in Android: move fast and fix things

#296

Post by pjmlp »

flohofwoe wrote: post #67
pjmlp wrote: post #60

Earlier quoted context omitted.

I expect Rust being documented here, https://developer.android.com/ndk I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust. I expect all NDK APIs to have Rust bidding crates. I expect that Android developer forums also care to support devs using Rust. And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and…

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

Nope it clearly supports ISO C 11 and ISO C++17.

I do agree the NDK team is rather small.

Re: Rust in Android: move fast and fix things

#297

Post by pjmlp »

flohofwoe wrote: post #290
cogman10 wrote: post #225

Earlier quoted context omitted.

I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated. [1] https://github.com/android/ndk-samples/tree/main/endless-tun...

Both Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.

CMake is the defacto tool adopted by the industry, regardless how many love to hate it.

You can use BSD Make instead of Gradle, isn't UNIX great?

Re: Rust in Android: move fast and fix things

#298

Post by tialaramex »

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.

> I’m a little perplexed why every time something in rust compiles, there’s a blog post about it

Crucially Rust is a very pleasant developer experience. Out of the box tooling is smoother, the compiler diagnostics are much better than peer languages†, the community are nicer, and so on. When you wrote safe Rust which compiles you get software that does what you wrote and not something else, which seems like a very basic thing to ask for but neither C nor C++ can do this. People respond well to a more pleasant environment.

† I wrote the one where if you write 'A' (the Unicode character capital A) but actually meant the ASCII byte 65 the diagnostic suggests writing b'A' instead rather than just telling you that what you wrote is a type mismatch.

Re: Rust in Android: move fast and fix things

#299

Post by pjmlp »

eggy wrote: post #93
pjmlp wrote: post #60

Earlier quoted context omitted.

I expect Rust being documented here, https://developer.android.com/ndk I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust. I expect all NDK APIs to have Rust bidding crates. I expect that Android developer forums also care to support devs using Rust. And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and…

Don't forget this list of expectations for SPARK [1] too, if you want even safer, high-integrity, and formally verified code on Android! [1] https://www.adacore.com/about-spark

Android has zero lines of Ada code, why should I care about it in this case?

Re: Rust in Android: move fast and fix things

#300

Post by androidcode »

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.

The blog post has a number of issues, including mixing C and C++. And Android C++ source code is often filled with C-style code, especially the older the code, and is not always that good in several aspects.

As an example, from https://android.googlesource.com/device/generic/trusty/+/c3f...

Many of the files in that commit have a lot of C-style code, yet are classified as C++. C and C++ are very different programming languages, and memory safety is arguably significantly easier to achieve in practice in C++ than in C, yet in the blog post, C++ is blamed for C-style code, and C and C++ are not differentiated.

Compare and contrast with https://android.googlesource.com/device/generic/goldfish/+/d... . That source code file has much more modern C++. Though even then, it contains goto, and modern C++ code reviews would normally not accept goto in my experience. I do not understand what Google Android is doing when its developers are using goto. Could they not have used lambdas in those places where they are using goto? The mixture of std::string_view and goto, modern and yuck, is disconcerting.

On a different topic, how much of the new Rust code is vendored dependencies? Is Fuchsia included?

Maybe the real value for Google Android that Rust holds, is that it mostly prevents C-style code from being written. And Rust does not support goto, and while I think an argument could be made that goto is OK to include in a toolbox, its usage should be very, very, very, very rare. Why does somewhat modern Google Android C++ allow goto?

I am not impressed by Google Android's C++ code quality. Are Google Android developers, independent of language, significantly below average?

C++ does have baggage, cruft and issues. But having strange C++ code (like goto) and also blaming C++ for C-style code, does not help paint an honest and accurate image. And if Google Android's C++ code review process accepts goto willy-nilly, I do not consider Google Android to be at all credible on any subject related to code quality, memory safety and security in any programming language.

Post reply on HN