Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

61–70 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#61

Post by moomin »

w8rbt wrote: post #5

If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.

Fastest to develop, yes. Portable, yes. Safest? Well, only in as much most of the errors will be blamed on the programmer for not doing the correct modern C++.

I mean, seriously, understanding the borrow checker is nowhere near as hard as understanding this: https://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwar...

There's a No True Scotsman aspect to C++ advocacy. Anything that is obviously dumb either is because the programmer did it wrong, because it belongs to the ever-growing list of features you avoid or "doesn't come up that often".

Re: Why you should, actually, rewrite some of it in Rust

#62

Post by w8rbt »

camus2 wrote: post #14
sebcat wrote: post #10

Earlier quoted context omitted.

Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C. (no true Scotsman)

> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?

Perhaps he means C11? The most recent standard (ISO/IEC 9899:2011).

https://en.wikipedia.org/wiki/C11_(C_standard_revision)

Re: Why you should, actually, rewrite some of it in Rust

#63

Post by the8472 »

gsnedders wrote: post #25
petters wrote: post #23

Earlier quoted context omitted.

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

The problem is they implementing their own memory management on top of the standard primitives; they never sent unallocated memory to the client.

rust can also help you make custom memory management safer, e.g. there are several arena crates which hand out allocations with lifetimes, which means the arenas won't be freed before all references went out of scope. And there also is no pointer arithmetic into the arena, you only interact with individual allocations. I don't know if it would have prevented heartbleed, but it enables 3rd-party allocators to provide the same safety guarantees as the rust standard lib does. Something that cannot be said about C because there are no safety guarantees in C in the first place.

Re: Why you should, actually, rewrite some of it in Rust

#64

Post by atemerev »

falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

> It was caused by failing to validate untrusted input. Rust isn't going to help you with that.

Really?

Validation and sanitization are the last, not the first line of defense. It is not about erecting barriers, it is about failure modes. All your software components, from core to border, should fail fast, safe and in a predictable way -- the exact opposite of what happens in C.

In any sane programming language (e.g. Java -- not particularly sane, but boring enough) Heartbleed would have resulted, at worst, in OutOfBoundsException or similar, and the only damage would have been the denial of service. And to do bounds checking, you don't need to have garbage collector -- it is the most basic thing the runtime can do, and performance penalty is minimal. Why it is customary to skip this in C/C++, I don't know.

Lack of bounds checking, not pointer arithmetic or allocation lifecycle, is the major source of security issues with existing software.

Re: Why you should, actually, rewrite some of it in Rust

#66

Post by klodolph »

the8472 wrote: post #63
gsnedders wrote: post #25

Earlier quoted context omitted.

The problem is they implementing their own memory management on top of the standard primitives; they never sent unallocated memory to the client.

rust can also help you make custom memory management safer, e.g. there are several arena crates which hand out allocations with lifetimes, which means the arenas won't be freed before all references went out of scope. And there also is no pointer arithmetic into the arena, you only interact with individual allocations. I don't know if it would have prevented heartbleed, but it enables 3rd-party allocators to provide…

There are some safety guarantees in C, it's just that Rust has more. Rust doesn't guarantee total safety, just like C doesn't mean no safety.

Re: Why you should, actually, rewrite some of it in Rust

#68

Post by Manishearth »

petters wrote: post #23
falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

It's ... debatable.

Heartbleed implemented their own memory management system (and had a bug in their use of it). This is pretty unusual even in C. It's extremely unusual in Rust, but who's to say that a similar implementation in Rust would come across the same challenges and implement their own memory management too? And write the same bug? Ultimately this kind of system would be unsafe code anyway, so Rust won't help you there. The question is if a Rust programmer would design such a thing (it's very non-Rust-y). The answer is probably "no". However, the same can be said about C programmers and the heartbleed code, so you have a bit of a no-true-scotsman vibe happening here.

So, yes, heartbleed could have happened in Rust too. I do feel it's less likely (Rust more strongly forces you to compartmentalize unsafe abstractions), but all of that is really debatable.

Re: Why you should, actually, rewrite some of it in Rust

#69

Post by Rusky »

snakeanus wrote: post #47
Shriken wrote: post #34

Earlier quoted context omitted.

All of your questions are addressed in the article. > Why Rust? Why not Idris? Why not Haskell? it can easily call C code it can easily be called by C code (it can export C compatible functions and structures) it does not need a garbage collector if you want, it does not even need to handle allocations the Rust compiler can produce static and dynamic libraries, and even object files the Rust compiler avoids most of t…

All of these except GC also hold true for the languages that I mentioned. As for GC, I think that Mercury avoids its use https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazu...

Nope- C interop is higher on the list for a reason. Idris and Haskell do not produce straightforward, runtime-less binaries that can be easily loaded by e.g. CPython or Node, without any interference with their runtimes.

Re: Why you should, actually, rewrite some of it in Rust

#70

Post by mamcx »

falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

Sometimes I wonder why developers are so masochist with his tools, and so MUCH AGAINST AUTOMATION.

If a language, for example, don't have NULLs and you need to use Sum Types (like ML or Swift) you have solved FOREVER and FOR ALL THE DEVELOPERS that problem.

But say that just because this is one problem among dozens, then is better FOREVER AND ALL THE DEVELOPERS to stay with the problem?

Instead, why not put as our goals to eliminate all the problems that are possible?

Post reply on HN