Cross-platform Rust rewrite of the GNU coreutils • Hacker News Board

Re: Cross-platform Rust rewrite of the GNU coreutils

#381

Post by jstimpfle » Tue, Mar 22, 2016, 11:07 PM UTC

tatterdemalion wrote: post #205

nickpsecurity wrote: post #175

Earlier quoted context omitted.

Holy crap, I'd never have imagined that... A design that assumes allocation always succeeds flies in the face of decades of safety/security-critical coding wisdom. I strongly recommend the team revisit and change that somehow to account for failures, NULL's, whatever. Actually, same anywhere a failure-prone, esp hardware, resource is acquired. C apps can handle this issue so Rust should as well if it's to replace the…

The standard allocator will abort on oom error. For applications which need to be tolerant to oom errors, you need to use a different allocator. Most programs can't tolerate oom errors, though, and it would be absolutely unreasonable for every function in the standard library that might perform an allocation to return an error that has to be handled by every programmer all the time. EDIT: C's solution is to make it v…

To be fair, not a bug in the language itself. Regarding libc, it's also very easy to abort on error. Just write a function xmalloc().

Re: Cross-platform Rust rewrite of the GNU coreutils

#382

Post by pcwalton » Tue, Mar 22, 2016, 11:08 PM UTC

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."

It's so common there's a tutorial on it: http://www.fuzzysecurity.com/tutorials/expDev/11.html

Re: Cross-platform Rust rewrite of the GNU coreutils

#383

Post by jstimpfle » Tue, Mar 22, 2016, 11:10 PM UTC

pcwalton wrote: post #382

jstimpfle wrote: post #373

Earlier quoted context omitted.

"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."

It's so common there's a tutorial on it: http://www.fuzzysecurity.com/tutorials/expDev/11.html

Thanks!

Re: Cross-platform Rust rewrite of the GNU coreutils

#384

Post by jahewson » Tue, Mar 22, 2016, 11:14 PM UTC

ehaughee wrote: post #355

jahewson wrote: post #294

Earlier quoted context omitted.

Of course I can read something and not copy it. I can read a book and not copy it. I can listen to a song and not copy it. I can look at art and not copy it. And I can read source code and not copy it. It's not surprising that your lawyer implied otherwise, as its "best practice" to guard against every feasible risk, no matter how unlikely. Understand that your lawyer is protecting you against a hyper-zealous misinte…

Correct me if I'm wrong, but it seems like the original point here is not whether someone read the code and then contributed, but whether their contribution might (inadvertently or otherwise) contain Matlab intellectual property because they have been exposed to it. It seems a reasonable safeguard to prohibit those who have seen the source code from potentially contributing in a troublesome manner.

You're quite right about exposure to code: it's prudent to be hyper-cautious. But the original point of contention was the suggestion that it's legally required to be this cautious, that people simply don't have the right to read something and then write something similar which isn't a copy - and that is false.

Re: Cross-platform Rust rewrite of the GNU coreutils

#385

Post by binarycrusader » Tue, Mar 22, 2016, 11:15 PM UTC

jordigh wrote: post #223

binarycrusader wrote: post #158

Earlier quoted context omitted.

Sometimes the maximising the likelihood of a set of components being used is more important than potential licensing constraints. In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts. Improving the general security and reliability of all systems seems like it might potentially be a more valuable goal.

> In this particular case, if they're not GPL, they're more likely to be used for various *BSD systems and in a variety of embedded contexts. This is a bit of a bugbear. The most common way to use the coreutils is through standard Unix pipes, which does not create a derivative work. I don't know of anyone who has found the copyleft of the coreutils prevents them from doing anything they would like to do. The situatio…

I understand and agree with your particular assertions about copyleft and unix pipes, etc. but disagree that it's a "bugbear".

I know from experience some organizations are perfectly willing to contribute changes back upstream on MIT/BSD-licensed components, but avoid GPL components simply because of the additional constraints and potential liability concerns that have to be dealt with. Apple is a perfect example given the additional conditions of the GPLv3.

Re: Cross-platform Rust rewrite of the GNU coreutils

#386

Post by pcwalton » Tue, Mar 22, 2016, 11:15 PM UTC

Dylan16807 wrote: post #351

pcwalton wrote: post #321

Earlier quoted context omitted.

Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up: http://llvm.org/docs/LangRef.html#undefined-values There's also the issue that having a stable value forces the register alloc…

> Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. It wouldn't allow nasal demons. Since LLVM seems to already have these semantics, it makes a good argument that it wouldn't hurt C's performance to tighten the spec at least that much. But I…

> What parts of the STL can be faster by treating uninitialized variables as impossible?

What I'm mostly thinking of is allowing unused branches to be pruned. The STL tends to get inlined really heavily, which results in a whole pile of IR being emitted for what look like very simple operations. Based on the actual parameters and state, the optimizer then wants to prune out as much dead code as possible to reduce i-cache footprint, and sometimes time as well.

Take small string optimization. That optimization requires a branch on length in almost every string operation. But if you have a std::string of constant size, you don't need the heap spilled code to be emitted at all. Usually the only way to work this out is inlining + constprop + DCE. That's where undefined value semantics are really helpful: a branch on an undefined value can be completely removed as undefined behavior, which can make its branch targets unreachable, and allow them to be removed, and so on recursively. Undefined values allow entire CFG subtrees to be eliminated in one fell swoop, which is an extremely powerful technique for reducing code size.

I don't have a precise example off the top of my head as to where this kicks in in the STL, but I strongly suspect it does.

Re: Cross-platform Rust rewrite of the GNU coreutils

#387

Post by jahewson » Tue, Mar 22, 2016, 11:17 PM UTC

realityking wrote: post #334

jahewson wrote: post #254

Earlier quoted context omitted.

No. It's not a derivative work. Creating a compatible piece of software is not copying. Even if you've seen the original code. If you're not literally copying and pasting code, it's fine. Copyright protects the code itself from being copied, but the ideas, abstractions, overall design, and even individual APIs are not eligible for copyright protection

The Federal Circuit Court of Appeals (and apparently the Supreme Court) would disagree with you on copyright protection for APIs. https://en.m.wikipedia.org/wiki/Oracle_America,_Inc._v._Goog... .

I knew someone would post this. Yes, that's technically correct, but 1) this could still go to the supreme court, 2) it's now back at the lower court for a ruling on whether copying APIs is "fair use" with all bets on the answer being "yes". So although I wouldn't dismiss the distinction, unprotected vs. fair use make no practical difference, we can copy freely either way.

Re: Cross-platform Rust rewrite of the GNU coreutils

#388

Post by cyphar » Tue, Mar 22, 2016, 11:18 PM UTC

quotemstr wrote: post #100

davexunit wrote: post #45

Earlier quoted context omitted.

They really should use the GPL and not a pushover license.

What is it with rewrite-the-world-in-Rust people being stridently anti-copyleft?

I don't understand it either. It's as though they want to ignore the history of free software, which simply wouldn't have happened without copyleft.

Re: Cross-platform Rust rewrite of the GNU coreutils

#389

Post by schoen » Tue, Mar 22, 2016, 11:21 PM UTC

_ZeD_ wrote: post #301

hnbroseph wrote: post #299

Earlier quoted context omitted.

the question seems non sequitur.

if you prefer "is free software dying"?

The MIT license is free and open source.

https://opensource.org/licenses/MIT

https://www.gnu.org/licenses/license-list.html#X11License

Maybe "copyleft" or "reciprocal" licensing?

Re: Cross-platform Rust rewrite of the GNU coreutils

#390

Post by cyphar » Tue, Mar 22, 2016, 11:23 PM UTC

randommodnar wrote: post #259

MIT license? Is open-source dying?

I don't like this trend of new projects choosing weak free software licenses. It's as though they wish to ignore the history of the world they live in -- free software would not exist in the form it does today without copyleft. Copyleft is the one defense free software developers have against corporate monopolies and proprietary splitting. For some reason though, everyone who works in $NewLang seems to not care about this at all.