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

261–270 of 430 posts

Re: Rust in Android: move fast and fix things

#261

Post by oconnor663 »

belval wrote: post #116
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.

Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.

Take a look at the examples in this post: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

Large C++ codebases have the same problems that large codebases have in any language: too many abstractions, inconsistent ways of doing things, layers of legacy. It comes with the job. The difference is that in C/C++, hard-to-read code also means hard-to-guess pointer lifetimes.

Re: Rust in Android: move fast and fix things

#262

Post by josefx »

Ar-Curunir wrote: post #44
pizlonator wrote: post #31

Earlier quoted context omitted.

I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices

This contradicts what Google has reported about their own code, which is that most vulnerabilities are in new code

I haven't looked at Googles style for c++ in a long time, but from what I remember it was actively hostile to best practices. Actively hostile to any improvement introduced by the language and actively hostile to the wider ecosystem of c++. Also Rob Pike was involved somehow at the time and that guy went around claiming that his C inspired GCed language would be the perfect replacement for C++ everywhere after the c++ standard simplified some common patterns for library authors because he was actively hostile towards reusable code.

I am not sure I even want to know what the average Google C++ codebase looks like.

Re: Rust in Android: move fast and fix things

#263

Post by tczMUFlmoNk »

ikety wrote: post #121
mkehrt wrote: post #111

Earlier quoted context omitted.

> great error handling Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function. On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's t…

Yep Rust approach won. Pretty much every new language is adopting Result style errors and it's been adapted to plenty of existing languages. It's a product of functional programming, and for me I can't see how you would ever want to handle errors outside of the functional programming railway-oriented style. For me it's just superior.

Umm, actually, it's specifically a coproduct of functional programming. ;-)

https://en.wikipedia.org/wiki/Coproduct

Re: Rust in Android: move fast and fix things

#264

Post by AlotOfReading »

bgwalter wrote: post #228
AlotOfReading wrote: post #191

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 . That's just a basic requirement of what it means to write in those languages. The graph about reverted code also addresses the "illegible bugs" argument. As for an analyzer, that's what ASAN is. I hope I don't need to explain why that's not a universal solution (even tho…

> 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, but you also might not depending on how the compiler feels that day.

Let's use an example: https://godbolt.org/z/TP6n4481j

The code shows main immediately calling a nullptr. What the compiler generates is a program that calls unreachable() instead. These are two different programs. If memory safety is "just" a bug, this would be a miscompilation. It's not a miscompilation though, because what I've given the compiler is something that resembles C++, but is actually some similar language where null dereferences are meaningful. The compiler only knows about C++ though and C++ doesn't have nullptr dereferences, so it assumes I haven't done that. Instead it generates a program corresponding to an execution trace that is valid C++, even if it can't see the call to NeverUsed(). If you use -O0, you get the segfault as expected.

A single instance of memory unsafety (or other UB) can take your program arbitrarily far from "correct". All other things being equal, a program with 1 violation might be just as incorrect as a program with 100. I could add a hundred more lines of safety violations after Do() without changing the compiled behavior. You don't even need to execute the unsafety to have "spooky action at a distance" cause that change.

[0] https://web.archive.org/web/20190406194101/http://colinm.org...

Re: Rust in Android: move fast and fix things

#265

Post by SkiFire13 »

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…

> For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics.

This assumes a self-balancing binary tree must have nodes with parent pointers. Without those you don't need reference counting and without that you don't need `RefCell` either.

Re: Rust in Android: move fast and fix things

#266

Post by baq »

josephg wrote: post #164
ActorNightly wrote: post #88

Earlier quoted context omitted.

The issue with most codebases is nobody thinks about starting out with acceptance testing system. The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on. This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And…

> The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests … Sometimes. It depends on what you’re working on. Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be mi…

> Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be misguided.

I see you sir haven’t had experience with writing drivers for prerelease hardware. You’re right in these cases of course, you just aren’t right enough - the real fun starts when you can trust neither the hardware, nor the BIOS, nor the OS in addition to all the above.

Re: Rust in Android: move fast and fix things

#267

Post by lmm »

kccqzy wrote: post #248
lmm wrote: post #242

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. I submit…

Any Rust code longer than ~20 lines uses Rust iterators which use type families. The Iterator trait in Rust has an associated type called Item. This is the innovation here. Classic type classes can only contain functions not types. It was in 2005 that a paper was written to show how having a type inside a type class makes sense, including how it can be type checked (via entailment of type class predicates with type e…

> Classic type classes can only contain functions not types...

> Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.

True, although I'm not sure how much difference it makes in a language with first-class modules. But more importantly, how much difference does it make at the point of use? As far as I can see the overwhelming majority of Rust iterator code looks pretty much the same as one would write in OCaml, or Java.

Re: Rust in Android: move fast and fix things

#268

Post by baq »

danudey wrote: post #68
nixpulvis wrote: post #21

Earlier quoted context omitted.

Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.

As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.…

The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills.

I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.

Re: Rust in Android: move fast and fix things

#269

Post by baq »

pizlonator wrote: post #58
dwattttt wrote: post #47

Earlier quoted context omitted.

> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion. Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?

In science, you go out of your way to control for confounding factors. This isn't that.

It’s a good start and even if error bars are wide enough to land a 747 in them their numbers show orders of magnitude scale differences. This should raise eyebrows at the very least in the biggest skeptics.

Re: Rust in Android: move fast and fix things

#270

Post by baq »

ActorNightly wrote: post #109
danudey wrote: post #91

Earlier quoted context omitted.

Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C! I…

>It's all nonsense, How is any of that wrong?

It isn’t wrong, it’s misguided. You can write the same code in a Turing machine, too.
Post reply on HN