Hacker News Reader

Comment by geofft | Hacker News Reader

It boggles the mind how people think the only benefit of Rust is memory safety. Rust has novel features for solving concurrency issues, what you call "pure LOGIC bugs (that include race conditions)".

Of course memory safety is one small piece of the entire puzzle. That's why Rust has features besides just being a memory-safe version of C.

View on HN

Read my post again cause you obviously didn't understand anything of what I wrote.

You can have 2 components written in 100% safe language with no memory corruption and no race conditions.

You can have security critical race conditions that arise out of the interaction of same components.

How is Rust or whatever solving this? It doesn't.

Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem.

If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."

You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are).

The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions.

And by subsystem I don't just mean pieces of code...

Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.

Buffer overflows seem to be a pretty recurring theme in these security issues, yep.

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

Rowhammer is a very good point. Hrm.

Rowhammer is basically mitigated if you don't let untrusted processes run CLFLUSH, right? That's sort of orthogonal to your choice of programming language (which might be your point, but then, I'm not sure I believe that Erlang or unikernels solves this either). It requires a world in which you've got something Native Client-like wrapping all userspace processes, which definitely seems like a good goal to work towards, and also seems easier to implement reliably in Rust than in C.

Row_hammer

You're citing a hardware flaw as a reason not to pursue programming tools and techniques that produce fewer software defects? That's a false dichotomy; we don't forego researching cancer treatments just because some of the people that are saved will end up getting shot.

Earlier you wrote "Security is all or nothing".

That's another amazingly bad point of view. There is no "all." Nothing is absolutely secure. There is only raising the bar. Important things are provided more protection than less important things. That is the best that can ever be achieved. Since your premise relies on a fiction your conclusions about the value of Rust are meaningless.

I agree that they are emergent behaviors between multiple systems. I am claiming that these individual components can capture knowledge of other components via strong type systems, and thereby eliminate race conditions. Can you explain why this is untrue?

I am trying to shift my thinking, but all I'm hearing is "No it can't." Can you explain why it can't?

This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that could violate type safety. I thought that argument was silly, and I think yours is too. Yes, I'm quite confident that Rust isn't a panacea, anymore than functional programming will be, or object oriented programming has been, or type safety is. The point is that each of those techniques helps you to avoid certain classes of bugs. And so far as I can tell, Rust genuinely does have features that make writing certain kinds of bugs much less likely. Yes, Rust doesn't help you prevent every kind of bug. (Shocker!) But I don't get the point of insisting that decreasing an attacker's surface space isn't worthwhile.

Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems.

For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code.

"Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.

Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.

I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist.

Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.

> No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.

You often don't even need Turing completeness.

"How is Rust or whatever solving this? It doesn't."

Actually, yes, it does. The borrow checker composes. Two correct Rust components for race conditions and memory safety will indeed compose together correctly. That's a great deal of the point of the whole thing, after all.

I don't think you've been keeping up with the state of the art in the last few years. Maybe less yelling and more listening is called for here.

Reply on news.ycombinator.com