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

301–310 of 430 posts

Re: Rust in Android: move fast and fix things

#301

Post by simonask »

AlotOfReading wrote: post #264
bgwalter wrote: post #228

Earlier quoted context omitted.

> You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all. The post you reply to does not indicate a misunderstanding of memory safety at all. .

The comment I'm responding to implicitly assumes memory safety violations are like other bugs where that it's meaningful to speak of programs being more or less correct depending on the number of issues. What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all. It's more like parsing paint splatters as perl [0]. You might get something resembling what you want if you're lucky, b…

Finally someone who actually gets it.

Many Rust proponents are experienced C and C++ developers who have dealt with this situation for decades. Given the language, it's understandable that compilers make the choices that they do. It's also understandable that programmers find it unreasonably difficult to reason about code written in such a language.

Re: Rust in Android: move fast and fix things

#302

Post by pjmlp »

androidcode wrote: post #300
kccqzy wrote: post #196

Earlier quoted context omitted.

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…

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

Re: Rust in Android: move fast and fix things

#303

Post by simonask »

justjulia wrote: post #292
array_key_first wrote: post #208

Earlier quoted context omitted.

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

That's valid, even sensible, but you have now left significant performance on the table.

Re: Rust in Android: move fast and fix things

#304

Post by androidcode »

pjmlp wrote: post #302
androidcode wrote: post #300

Earlier quoted context omitted.

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…

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason.

Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.

Re: Rust in Android: move fast and fix things

#305

Post by flohofwoe »

pjmlp wrote: post #297
flohofwoe wrote: post #290

Earlier quoted context omitted.

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?

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

So the NDK officially supports creating an APK just with a Makefile? That would be news to me (and great news at that).

It is possible to cobble together a build process that directly calls various Android SDK command line tools to build an APK directly from a C/C++ build tool without involving Gradle, but as far as I know, most of those invoked cmdline tools are deprecated and building APKs outside Gradle is not 'supported' by the Android SDK/NDK (e.g. it may stop working at any time).

Re: Rust in Android: move fast and fix things

#306

Post by androidcode »

pjmlp wrote: post #302
androidcode wrote: post #300

Earlier quoted context omitted.

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…

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

BTW; Do you know if it is possible to track new comments to Hacker News threads?

Re: Rust in Android: move fast and fix things

#307

Post by pjc50 »

pityJuke wrote: post #120
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.

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).

> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.

We're decades into the global warming era. You simply can't make some people accept evidence if the conclusions from that evidence would be uncomfortable to them.

If people don't take exploitability seriously, you can't make them. Well, unless you keep pwning them.

Re: Rust in Android: move fast and fix things

#308

Post by mx7zysuj4xew »

imiric wrote: post #169
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).

I think that it would be foolish for any software engineer to completely dismiss any technology. There is a time and place for any tool, and it is a job of a competent engineer to determine what the appropriate combination of these is that would solve a certain problem within specific constraints. That said, memory safety is one criterion out of many that could be used to make that decision. For a large number of sof…

I dont so much dismiss the technology as the people who insist on rewriting everything in rust.

Rust seems to attract a certain mindset of mediocre programmers who yell "security" to shove their poorly written slower code down our throats.

Most of them seem to be former web developers who bring all their npm drama to stable C foundations

Re: Rust in Android: move fast and fix things

#309

Post by mx7zysuj4xew »

wakawaka28 wrote: post #197
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).

One who has tried the language and hates it can completely dismiss it. Memory issues can be fixed in ways that don't involve rewriting millions of lines of code and the ensuing chaos, feature degradation, retraining, etc. that goes with it.

Your reply isn't necessarily "polite" but your reaction and is entirely appropriate considering the headaches these people are bringing

Re: Rust in Android: move fast and fix things

#310

Post by mx7zysuj4xew »

dgacmu wrote: post #159
linkage wrote: post #150

Earlier quoted context omitted.

> I cannot see why in the face of astounding evidence like this, you would completely dismiss it. Because it's not a silver bullet. That safety comes at a cost; Rust is much more difficult to learn than C or Zig and the compilation time for code with equivalent semantics is an order of magnitude greater. It has also added a great deal of toolchain complexity to projects like the Linux kernel. People have decided that…

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…

How about you teach some of those students to Bootstrap a Linux cross compile both with and without rust then come back and answer this reply again
Post reply on HN