Hacker News Reader

Comment by zanny | Hacker News Reader

This is why Rust is so promising. The problem at Apple / MS / Linux / etc is they are massive houses built on bare foundations. Everything traces its roots back to C, and back to exploitative vulnerabilities in the code. Rust itself is not close to safe since it depends on LLVM which itself can be a source of myriad bugs related to C++.

But its proving in my experience to be a much more practical foundation, and going forward there is a lot of value in that.

View on HN

this isn't a code error -- it's a logic error. No amount of "safeness" in the language will save you from telling the language, without breaking the rules, from doing something that is "wrong".

For instance:

    sudo rm -rf /

Every part of that is completely sound and correct. There are no buffer overflows, emory corruption, or anything. You wrote a completely correct command to do something (probably) really wrong.

This is preventable if you specify fully what you actually want to do.

Then there are systems that just prevent ambiguous rules if you really dig into it. (Speaking of assisted theorem prover such as Coq and Isabelle.)

>This is preventable if you specify fully what you actually want to do.

In this case it was fully specified that sudo should run rm with all privileges, which in turn will recursively deleted the root filesystem.

The entire execution is fully specified and will execute without fault. There is no mistake in `sudo rm -rf /`.

Logical faults may not be preventable with provers, such as when underlying assumptions are wrong.

For example, a prover could have verified the parity library as fully okay because it assumes that the initialization function will not be called without delegation. This underlying assumption X -!> Y (X cannot lead to Y) is wrong and X -> Y is the case but the prover only verified that Y -!> X.

Provers essentially duplicate your code, forcing you to express the solution and/or problem twice such that if you basically typo on the way, one of the pieces will complain about the other.

But it cannot and is incapable of preventing higher level mistakes.

The bug in question isn't related to memory safety, overflow, or concurrency, though.

Better languages can help to avoid certain classes of errors, but won't prevent bugs in the business logic of your code, so I'm not sure how this is relevant to contracts.

We do occasionally run into bugs between Rust and C++ semantics with LLVM, but they’ve been pretty minor, and LLVM has largely fixed them, to the point of adding instrinsincs to fix these issues.

Bugs happen no matter the language, even if LLVM was in Rust it would have them.

Has there ever once been a critical llvm vulnerability? I've seen the occasional bugs related to it, but they tend to crash the compiler rather than produce bad binaries, no?

Here's a list of LLVM bugs found using Csmith: http://embed.cs.utah.edu/csmith/llvm-bugs.html . Plenty of these are wrong code bugs.

Security-related compiler bugs very rare, but they do exist, at least in graphics shader compilers: http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2017/OOPS... . My impression is that many of these shader compilers are based on LLVM, but this is mostly conjecture. (I do recall a video game crashing on me with internal LLVM errors from the graphics driver.)

Reply on news.ycombinator.com