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

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

151–160 of 504 posts

Re: Getting Past C

#151

Post by pjmlp »

ArkyBeagle wrote: post #72
dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

C is the new "goto". Y'all please, please note that dreta said "... an array implementation that prevents that from ever happening..."

C is the PHP and JavaScript of the 70's.

Re: Getting Past C

#152

Post by Manishearth »

afarrell wrote: post #78
panic wrote: post #69

Earlier quoted context omitted.

And it only takes one programmer mistake to bring the whole house of cards down. Isn't this also true of Rust, with its unsafe keyword? None of these languages are completely safe against programmer mistakes.

Is the use of the unsafe keyword a default? I don't know Rust, but from a user interface perspective, it sounds like it has an affordance of "Hey! Pay particular attention to this bit because it is risky!"

It's more of a "Hey, trust me here when I say that the enclosed code is actually safe" hint to the compiler.

It's used sparingly. Not as sparingly as I'd like, but sparingly enough.

Re: Getting Past C

#153

Post by the_duke »

zzzcpan wrote: post #145

After reading this post the idea of a C-to-C translator that injects bound checking, etc. comes to mind. Such translator could be used by OS distributions to provide safety in the least intrusive way and possibly completely automatically for many C codebases they have in their repositories. Translating into Go or Rust, on the other hand, cannot scale beyond some individual projects, that decide to undertake such effo…

It's a shame, really, but if you could write a decent C to safe Rust transpiler, than Rust probably would not exist.

Lifetime inference etc is a hard problem, and if it could be done right now, compilers would just have static checks for all that.

There is a C to UNSAFE Rust transpiler, though: https://github.com/jameysharp/corrode.

Re: Getting Past C

#154

Post by Manishearth »

lossolo wrote: post #87
nothrabannosir wrote: post #62

Earlier quoted context omitted.

You can't implement certain things in C if you are on the quest for maximum efficiency. Thankfully, one rarely is, because efficiency isn't binary. It's about trade-offs.

I could say exactly the same for Rust, that it's not enough even using unsafe keyword and I need to go into assembly. Someone could even say that assembly is not enough and we need FPGA and then ASIC etc. But it's not the point here. The point is that for ex. you can't get safety from out of bounds access without bound checking, doesn't matter which language you use. And bound checking for certain hot paths is not ac…

> doesn't matter which language you use

Idris.

Re: Getting Past C

#155

Post by lossolo »

pjmlp wrote: post #148
dreta wrote: post #126

Earlier quoted context omitted.

No language you use can get around syscalls, so i have no clue as to why this is a case against C.

Not all OSes have unsafe syscalls, nor do all OSes have to be implemented in C.

But the most used are and I can't see it change anytime soon.

Re: Getting Past C

#156

Post by Veedrac »

jdmichal wrote: post #47
staticassertion wrote: post #40

Earlier quoted context omitted.

Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax. Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires…

In addition, the Rust compiler can also remove the built-in indexing checks if it can prove the code is safe. So, say, iterator loops over an array won't have any index checking.

Iterator loops are different. They don't elide bounds checks automatically, like frequently claimed. Instead they merge it with the loop branch, so there's no redundant checking.

Re: Getting Past C

#157

Post by dhsjxhx »

bvinc wrote: post #144
dhsjxhx wrote: post #113

Rather than looking for a new language, why not ban programs from writing to executable memory?

I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too. But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program…

>A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened.

I don't know about rust, but you can have an ArrayOutOfBoundsException in Java, and equivalent in Go and other safe languages

Re: Getting Past C

#158

Post by Manishearth »

lossolo wrote: post #36
naasking wrote: post #35

Earlier quoted context omitted.

> i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up when trying to work with memory in Rust. False. Buffer overflows in C can overwrite the program's memory, so it can be hijacked and supplanted with the attacker's code. This cannot happen in Rust (unless unsafe code has the vulnerability), or any memory safe language. Sure you can implement a safe array…

I think he means to work with raw memory so using unsafe keyword and in this case he is right. And you can't implement certain things in Rust if you are on the quest for maximum efficiency without using unsafe.

This is throwing the baby out with the bathwater though.

You need unsafe to do some things in Rust, sure. But usually this code is isolated and auditable, and nowhere near the linecount of the rest of the application. Even the operating systems written in Rust have pretty conservative use of unsafe (redox, Phil's OS, etc). Most of your code won't be working with raw memory operations, most of it will work with zero-cost abstractions on top of raw memory.

Re: Getting Past C

#159

Post by lossolo »

Manishearth wrote: post #154
lossolo wrote: post #87

Earlier quoted context omitted.

I could say exactly the same for Rust, that it's not enough even using unsafe keyword and I need to go into assembly. Someone could even say that assembly is not enough and we need FPGA and then ASIC etc. But it's not the point here. The point is that for ex. you can't get safety from out of bounds access without bound checking, doesn't matter which language you use. And bound checking for certain hot paths is not ac…

> doesn't matter which language you use Idris.

Care to elaborate? I don't see how this can be done without trading space/time over solution without bound checking.

Re: Getting Past C

#160

Post by ArkyBeagle »

ArkyBeagle wrote: post #72
dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

C is the new "goto". Y'all please, please note that dreta said "... an array implementation that prevents that from ever happening..."

Final word on the subject - what we have is people who are trying to make Open Software Reputation Points by finding a problem and fixing it, rather than waiting to find a real problem and fixing that.

When the figure of "ten minutes" was used - that's really what it should be as a mean or median figure, with some long-tail outliers for knotty cases.

While I am (somewhat) sympathetic, I don't miss what it is - it's make-work. There's not some body of material on language, O/S and software design available today that wasn't available 40 years ago. People new better back then, and didn't do better.

But the endless, circular, Utopian arguments just don't cut it. It ain't the crate, it's the pilot. I am sorry that oh so many are put upon to actually - gasp - test their code but that's what this is.

The economics of a Rust or Go or whatever make perfect sense - in the long run. Just recall what Keynes said about the long run.

Post reply on HN