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

Cross-platform Rust rewrite of the GNU coreutils

github.com

Post reply on HN
Print view View original

371–380 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#371

Post by kbenson »

pcwalton wrote: post #237
adrusi wrote: post #148

Earlier quoted context omitted.

Undefined behavior is not always identifiable through static analysis. Obviously it can be checked against at runtime, but that's actually quite expensive. It would, for example, include bounds checks for everything, and overflow checks on all signed arithmetic.

That's not the worst of it: the truly intractable part is preventing use-after-free UB. The only ways to do this are (a) remove malloc from your language; (b) add a lifetime system (incompatible with all existing C libraries); (c) add a garbage collector (which most projects written in C will not accept for performance reasons).

I think that's mostly solved by changing the whole of the idea from "remove/disallow all undefined behavior" to "remove as much of the common needed undefined behavior as possible such that most programs need not really use it". Perfect is the enemy of good.

Re: Cross-platform Rust rewrite of the GNU coreutils

#372

Post by JulianMorrison »

DannoHung wrote: post #353
JulianMorrison wrote: post #320

Earlier quoted context omitted.

A rewrite automatically makes things worse because you start with no code . I figure it's one of the signs of programmer maturity, that you start to look askance at rewrites. So tempting, yet so rarely even finished let alone better.

In the case of Rust I don't believe this is 100% true given C ABI compatibility. You could start rewriting in such a way that it is integrated with the existing code and slowly, but surely tease the C out of the system.

It would for the longest time be a C program with a metastasizing wart of Rust hung off the side, impossible to get into, impossible to work with, debugging hell, compilation hell. The distros would weep.

Re: Cross-platform Rust rewrite of the GNU coreutils

#373

Post by jstimpfle »

steveklabnik wrote: post #367
jstimpfle wrote: post #366

Earlier quoted context omitted.

I don't think you can count use-after-free as exploitable. Sure, if you have them (and I think those cases can largely be ruled out by good design), it leads to crashes. But for memory type exploits you need control over the value in it. Not a security specialist but I'm not aware of common attacks besides overflowing buffers. In hot paths (like codecs, compression algorithms...) I'm sure you never want bounds checki…

https://www.owasp.org/index.php/Using_freed_memory

"While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack."

Re: Cross-platform Rust rewrite of the GNU coreutils

#374

Post by jahewson »

npizzolato wrote: post #357
jahewson wrote: post #285

Earlier quoted context omitted.

Your lawyers are peddling FUD because they make money that way. "Hey, it looks like you need another legal agreement, can't be too safe!" The reality is that an "unintentional copying" claim against source code makes for a very weak lawsuit and it's close to unimaginable that such a case would even make it into a court room. You're free to read whatever you like. Don't let anybody tell you otherwise.

You're giving a lot of strongly-worded advice/opinions on legal issues in this thread. Are you a lawyer? Can you point to any case-law to back up what you're saying? I'm not a lawyer, and I don't really know who's right in this thread, but I'd find any citations you have really interesting to read.

Here's an crazy thought: when lawyers are in court, one of them is always wrong. Imagine that. A lawyer being wrong. Mind blown. Is your lawyer a software engineer? If not, he doesn't know anything! He has literally no idea. He can't even comprehend software. It would melt his brain.

So you ask, how can I the holder of meagre so-called "Computer Science PhD", comprehend the the holy (and unspeakable) knowledge of those who have spent an unimaginable three years studying law? Who am I to question our very gods? Well, sir, I give you "The Wikipedia":

https://en.wikipedia.org/wiki/Clean_room_design#Examples

Perhaps we should have it destroyed for spreading the "unspeakable" knowledge, rightfully known only by our lawyer-priests and spoken amongst them in their own tongue.

Re: Cross-platform Rust rewrite of the GNU coreutils

#375

Post by pcwalton »

AnimalMuppet wrote: post #356
pcwalton wrote: post #330

Earlier quoted context omitted.

> Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have. The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues. C is worse. > There are definitely issues with C no doubt--but so many people say C i…

> The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues. Examples? I'd be surprised if best practice C++ (C++11, say) had memory safety issues. (I realize that's only the last half- decade...) > C is worse. Certainly. Lack of destructors alone makes it hard to create safe abstractions.

> Examples? I'd be surprised if best practice C++ (C++11, say) had memory safety issues.

Pwn2Own last week. For more examples, search any browser engine's bug tracker.

Yes, this is all modern C++.

Re: Cross-platform Rust rewrite of the GNU coreutils

#376

Post by comex »

jstimpfle wrote: post #373
steveklabnik wrote: post #367

Earlier quoted context omitted.

https://www.owasp.org/index.php/Using_freed_memory

"While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack."

I have no idea what that article is talking about. Use-after-free exploits have been extremely common for years. Like I said, look at Pwn2Own (which requires submitting an actual working exploit): https://www.google.com/search?q=pwn2own+use-after-free

Re: Cross-platform Rust rewrite of the GNU coreutils

#377

Post by [deleted] »

mc808 wrote: post #349
randommodnar wrote: post #259

MIT license? Is open-source dying?

I was going to say it only takes about 30 seconds to fork and change the license if you want to. Then I decided to check if someone had already done so. Yep. https://github.com/ivegotasthma/coreutils/commit/4c7dcbd912a... I didn't count, but that may have taken less than 30 seconds.

[deleted]

Re: Cross-platform Rust rewrite of the GNU coreutils

#378

Post by pcwalton »

JulianMorrison wrote: post #372
DannoHung wrote: post #353

Earlier quoted context omitted.

In the case of Rust I don't believe this is 100% true given C ABI compatibility. You could start rewriting in such a way that it is integrated with the existing code and slowly, but surely tease the C out of the system.

It would for the longest time be a C program with a metastasizing wart of Rust hung off the side, impossible to get into, impossible to work with, debugging hell, compilation hell. The distros would weep.

Programs written in multiple languages are not exactly a new thing. Every iOS and Mac app is one, just to name one example.

And Firefox has a good chance to become exactly what you describe with the weird cancer analogy--in fact, the nightly builds already are.

Re: Cross-platform Rust rewrite of the GNU coreutils

#379

Post by Manishearth »

pcwalton wrote: post #95
masklinn wrote: post #39

Earlier quoted context omitted.

I expect it's because because the first part is essentially preaching to the choir, and because Richard Hipp very much disagrees with the second part[0] > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. (see link for expansion on that matter, which is a question of tooling and testing) [0] http://blog.regehr.org/archives/1292#comment-18452

Disappointing to see Hipp make that argument. It's trivially refuted. Yes, all programming languages allow the programmer to write bugs. But languages very much vary in how many , and what kinds of bugs programmers write in practice . Saying "well, Rust doesn't eliminate all bugs" is attacking a straw man. If you want to argue that Rust isn't worth it, you need to convince me that C plus gcov results in fewer bugs in…

Nor does Rust let you trigger "dangerous" UB in non-unsafe code. This isn't going to change, ever, so the argument that "give it time, Rust will soon be chock-full of UB" is moot too.

Re: Cross-platform Rust rewrite of the GNU coreutils

#380

Post by pcwalton »

jstimpfle wrote: post #366
comex wrote: post #350

Earlier quoted context omitted.

> I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces. The borrow checker eliminates use-after-free. And use-after-free is one of the most common types of vulnerability exploited in practice today, if not the single most common. (For evidence, look at reports about Pwn2Own.) Index checking is quite cheap for most programs, and LLVM is good at eliminatin…

I don't think you can count use-after-free as exploitable. Sure, if you have them (and I think those cases can largely be ruled out by good design), it leads to crashes. But for memory type exploits you need control over the value in it. Not a security specialist but I'm not aware of common attacks besides overflowing buffers. In hot paths (like codecs, compression algorithms...) I'm sure you never want bounds checki…

Use after free is a really common form of RCE. Have you heard the term "heap spray"? That's an exploitation technique for use after free.
Post reply on HN