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

341–350 of 430 posts

Re: Rust in Android: move fast and fix things

#341

Post by vacuity »

Jweb_Guru wrote: post #287
vacuity wrote: post #158

Earlier quoted context omitted.

Yes. I would make a guess of 10 or less memory-safety vulnerabilities per MLOC, which is still a hundredfold reduction.

Your best guess is that the true rate is 20x higher than the observed rate? This seems unlikely to me given the number of samples (outside of systematic biases towards certain types of memory safety bugs that probably apply to C++ code too). 10 per hundred MLOC is closer to what I would have guessed too, but that is because I've historically been very conservative with my assumptions about the memory unsafety rate pe…

I'm making a conservative guess, which is why I said 10 or less (10 or fewer??). So the improvement is at least a hundredfold. I might say 5 or less instead. I think the exact rate is not so important; either way, it's clear that Rust is a boon.

Re: Rust in Android: move fast and fix things

#342

Post by bluGill »

apitman wrote: post #254
bluGill wrote: post #133

Earlier quoted context omitted.

Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.

If you find yourself doing a lot of cross compiling C check out the Zig build system.

I am not going to rewrite the build system of a third party library.

Re: Rust in Android: move fast and fix things

#343

Post by pjmlp »

flohofwoe wrote: post #336
pjmlp wrote: post #330

Earlier quoted context omitted.

Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.

The one great feature of Emscripten is that you can do: emcc hello.c -o hello.html ...and it produces an output that's immediately runnable in a web browser instead of just a bare .wasm file which needs to be wrapped in a html with additional steps. E.g. emcc is a drop-in replacement for gcc/clang which can be used directly in a C/C++ build tool as a C/C++ compiler and linker while still doing the right thing (produc…

Usually applications aren't bare bones hello world.

It is not ivory tower, it is called OS safety, and the NDK purpose has been quite clear on its front page documentation since Android 2.x.

Likewise, from my side, I don't consider those speed bumps on Emscripten features.

Re: Rust in Android: move fast and fix things

#344

Post by tialaramex »

jkrejcha wrote: post #323
AlotOfReading wrote: post #264

Earlier quoted context omitted.

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…

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

Re: Rust in Android: move fast and fix things

#345

Post by blub »

josephg wrote: post #313
blub wrote: post #278

Earlier quoted context omitted.

The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions. If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc. Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what id…

> If a language is hard to write at first, it’s always hard to write. That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time. Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?

You’re mixing up developers becoming more competent with the language becoming easier.

Neither C++ nor Rust are becoming easier unless new features are added which make them simpler to use in some circumstance.

C++11 & co did make many things simpler. For Rust I don’t know the details of what’s upcoming; it doesn’t seem to be getting simpler.

Re: Rust in Android: move fast and fix things

#346

Post by surajrmal »

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…

Bugs don't need to be exploitable to be a problem. The program is incorrect and invariably will fail to act correctly due to those bugs.

Modern c++ has none of the advantages I mentioned. std::variant is cumbersome to use and you cannot easily match on it exhaustively, std::optional and std::expected have UB if you look at the stored types without checking if it's valid first. I love c++ and still use it daily, but I also know I write more bugs when I use it compared to rust. I don't have hard proof that rust is less prone to other types of bugs but wouldn't be surprised if someone produces a blog post with evidence. If you're trying to make judgement without experience, then that's simply foolish.

I'm not sure why you would point to "bigness" of the language as a problem when you're fine with considering c++ a systems language. If you don't like cargo, you don't have to use it. There are other build tools that can integrate with the rust toolchain the same way you would do so with c++. If some libraries are not suitable, don't use them. There are plenty of c++ libraries like boost which I avoid because they don't work well for me too. Consider the way in which The Linux kernel is using rust the language. The key to whether a systems programming is useful is whether I can meet the constraints the software must run in, typically in terms of binary size, memory usage, and runtime performance. Rust delivers here and can be used anywhere c/c++ have found success.

Re: Rust in Android: move fast and fix things

#347

Post by jamincan »

lmm wrote: post #242
kccqzy wrote: post #198

Earlier quoted context omitted.

One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system. So the ans…

> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system. I submit…

All of the memory safety stuff is independent of the trait system, to the best of my knowledge, but the data race protection is implemented through the Send and Sync traits. I'm unsure if there is an obvious alternative approach to this same feature, but I think it may be one innovation that is still novel to Rust and would not have existed in earlier decades.

Re: Rust in Android: move fast and fix things

#348

Post by steveklabnik »

blub wrote: post #345
josephg wrote: post #313

Earlier quoted context omitted.

> If a language is hard to write at first, it’s always hard to write. That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time. Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?

You’re mixing up developers becoming more competent with the language becoming easier. Neither C++ nor Rust are becoming easier unless new features are added which make them simpler to use in some circumstance. C++11 & co did make many things simpler. For Rust I don’t know the details of what’s upcoming; it doesn’t seem to be getting simpler.

A significant amount of Rust’s “new” features over the last years have been “yeah if you tried to use x and y together, that didn’t work, but now it does.” From an end user perspective, a lot has been made more straightforward over time.

Re: Rust in Android: move fast and fix things

#349

Post by surajrmal »

blub wrote: post #293
bgwalter wrote: post #181

Earlier quoted context omitted.

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…

While crashing is better than exploitable behavior, catching bugs at compile time is even better. Neither hardware based strategies nor filc actually find bugs at compile time. Also the conversation with respect to security isn't about migrating old code, but what to use for new code that you write.

I will note that developers also feel more productive in rust. That's why they migrate existing things over to it even when it may not be beneficial for security.

Re: Rust in Android: move fast and fix things

#350

Post by [deleted] »

jkrejcha wrote: post #323
AlotOfReading wrote: post #264

Earlier quoted context omitted.

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…

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

[deleted]
Post reply on HN