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

141–150 of 504 posts

Re: Getting Past C

#141

Post by pjmlp »

mistaken wrote: post #109
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…

To be fair the [] syntax is an overridable operator and you could just point it to use the "at" method. Not sure why they've implemented it as an usafe function.

It is, if you are using VC++ debug builds or define the macro for secure STL.

The idea of ANSI C++ was to provide safety behind library calls instead of compiler switches.

Re: Getting Past C

#143

Post by pjmlp »

loup-vaillant wrote: post #115
mistaken wrote: post #109

Earlier quoted context omitted.

To be fair the [] syntax is an overridable operator and you could just point it to use the "at" method. Not sure why they've implemented it as an usafe function.

With C++, the default is zero overhead, not safety.

Not 100% true when using the standard library and compilers like VC++, which do provide such checks in debug builds, while allowing to selectively turn them on, on release builds.

Re: Getting Past C

#144

Post by bvinc »

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 behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program.

But even if you solve the security issues, buffer overflows are still a huge headache. A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. A developer can easily spend weeks tracking down a single buffer overflow crash.

Re: Getting Past C

#145

Post by zzzcpan »

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 efforts. Mainstream C compilers could implement safety features too, but realistically it cannot happen, as it's not something most people care about. So, C-to-C translator might be a best bet with the most impact.

Re: Getting Past C

#146

Post by pjmlp »

jdmichal wrote: post #66
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…

Obviously, one can program C to do anything, and write all the provably safe abstractions wished. But, that's not really the point. The point is that doing such is not the default. It requires engagement and knowledge of the programmer, especially on distributed projects with loose communication, such as many open source projects. And it only takes one programmer mistake to bring the whole house of cards down. Why al…

Even in the 70's there were better alternatives outside AT&T walls, e.g. at Burroughs.

Re: Getting Past C

#147

Post by sidlls »

EugeneOZ wrote: post #133
staticassertion wrote: post #104

Earlier quoted context omitted.

> How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases. Certainly. I didn't intend to imply otherwise. > Also, "safe by grep audit" means "safe according to a human." Again, totally correct here. > The argument of course is that it lowers the surface area of what a human must be trusted to verify. I'm still not convinced by that argument, beca…

Rust is safe in terms of memory usage and race conditions, nobody claims that Rust compiler will catch all 100% of bugs human can invent.

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

Re: Getting Past C

#148

Post by pjmlp »

dreta wrote: post #126
qznc wrote: post #31

Earlier quoted context omitted.

Libc does not use your safe array. You cannot pass your safe array to read and other syscalls.

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.

Re: Getting Past C

#149

Post by steveklabnik »

sidlls wrote: post #147
EugeneOZ wrote: post #133

Earlier quoted context omitted.

Rust is safe in terms of memory usage and race conditions, nobody claims that Rust compiler will catch all 100% of bugs human can invent.

Rust is safe by default in terms of memory usage. It is not, however, strictly memory safe. It is trivial to overflow a buffer in Rust, for example. I haven't discovered a trivial way to hide it, though.

If Rust is not memory safe in safe code, then you've found a bug. Please report it to https://www.rust-lang.org/security.html

Re: Getting Past C

#150

Post by Manishearth »

lacampbell wrote: post #88
staticassertion wrote: post #67

Earlier quoted context omitted.

I didn't claim that rust would be faster than C (not that it can't be) in that situation. I would expect very similar performance. I'm not feeling very well unfortunately, not really in the mood to code.

I just keep hearing about how rust handles safe bounds checked arrays with (and I quote) "Zero-cost abstractions", which to me implied it would be faster than C, since C pays some performance penalty by branching. Hope you feel better soon.

"Zero cost abstraction" means that the abstraction doesn't impose an additional cost. It is the same cost of branching that C will have, modulo optimizations.

(Languages with dependent types can help move bounds checks to compile time, but Rust does not have those)

Post reply on HN