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

71–80 of 504 posts

Re: Getting Past C

#71

Post by jdcarter »

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.

Go also does this as of version 1.7:

http://www.tapirgames.com/blog/golang-1.7-bce

Re: Getting Past C

#72

Post by ArkyBeagle »

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

Re: Getting Past C

#73

Post by dragontamer »

falcolas wrote: post #14
IshKebab wrote: post #10

Earlier quoted context omitted.

ATmega is not really a popular architecture any more. It only stuck around because of Arduino, and even that is moving towards ARM. Nobody is going to be running NTPsec on it in any case!

What arduino-class (that is, low power microcontrollers) devices are moving towards ARM? Seems like a very different use case from portable computers (like the Raspberry Pi) - the power consumption differences are pretty major. > Nobody is going to be running NTPsec on it Never say never. :) There are wifi, ethernet, and clock shields for Arduino, all of which are running microcontrollers, and many applications which…

> Never say never. :) There are wifi, ethernet, and clock shields for Arduino, all of which are running microcontrollers, and many applications which would benefit from using NTP.

FYI: Microcontrollers really ought to just be interpreting the WWVB radio signal (aka: the 60,000 Hz Atomic Clock radio signal throughout the entire continental USA). Alternatively, Microcontrollers easily connect up to GPS modules for an alternative radio signal / alternative time source.

If anything, Microcontrollers are a great interface to the 60kHz Atomic Clock signal and are therefore would probably be the best NTP-server.

In any case, the "real" best architecture is probably a microcontroller doing Radio Logic / digital signal processing for WWVB, and that is connected through a simple connection (ex: I2C that says the last announced time from the WWVB signal) helping a "bigger" Raspberry Pi. And the Raspberry Pi can handle the ethernet / server stuff

Re: Getting Past C

#74

Post by kazinator »

jstimpfle wrote: post #58
geofft wrote: post #52

Earlier quoted context omitted.

And once you have written a five line safewrite() function, a hundred-line saferecvfrom() function, a 1500-line safeioctl() function, and all of that, and you have a third-party static analysis tool to prove that you're never calling the unsafe read() or ioctl() functions except from the wrappers, what was the advantage of staying in C in the first place?

I see where you are going, but I don't get how you get from 4 to 5 to 100 to 1500?

safeioctl may have to contain a redundant switch (or more OOP-style dipatch across multiple functions) on the command code in order to convert the safe style arguments to each specific low level ioctl call. That sort of thing can easily explode in line count. I can see exactly what geofft is talking about.

Re: Getting Past C

#75

Post by Ericson2314 »

civility wrote: post #53
Ericson2314 wrote: post #45

Earlier quoted context omitted.

Nope. Iterators in Rust can be used to safely avoid bounds checking in ways that would be impossible to enforce in C.

We were talking about reading into a bounds checked array. Rust does not user iterators for this.

I cannot trust people to correctly iterate in order through an array in C, and thus must resort to bounds checking them.

Re: Getting Past C

#76

Post by sidlls »

staticassertion wrote: post #40
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…

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…

How do you suppose runtime bounds checks are done in Rust? They certainly also incur a performance penalty in not-trivial cases.

Also, "safe by grep audit" means "safe according to a human." 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, because human error is a thing. And for actual systems programming, "very rare" may not be true.

Re: Getting Past C

#77

Post by pjmlp »

lacampbell wrote: post #56
Animats wrote: post #42

Earlier quoted context omitted.

The track record of two decades of CERT advisories for buffer overflows suggests that doesn't work in practice.

Just because people fail to do something doesn't mean it's not both possible and easy.

I have been hearing and reading that from C advocates since 1993.

It only got worse.

Re: Getting Past C

#78

Post by afarrell »

panic wrote: post #69
jdmichal wrote: post #66

Earlier quoted context omitted.

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…

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

Re: Getting Past C

#79

Post by staticassertion »

panic wrote: post #69
jdmichal wrote: post #66

Earlier quoted context omitted.

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…

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.

Totally. But in the case of rust your vulnerabilities are grep'able. For all of the code you have in a project you only have to search for the unsafe keyword when you want to audit it.

I think that makes a very significant difference.

Re: Getting Past C

#80

Post by mitchty »

eridius wrote: post #64
falcolas wrote: post #9

Earlier quoted context omitted.

Well, it's not just older architectures which are not currently supported, it's architectures used in IOT devices, mainframes, and other non-commodity hardware. Specific to LLVM based languages, if it's not a priority to Apple (or the other big LLVM players), it infrequently gets done. Specific to IOT devices, I would personally love to see secure everyting . NTP, TLS, SSH, etc.

There is a lot of community interest in Rust with regards to running on embedded devices, so I wouldn't be so quick to point to IOT devices as a reason for not using Rust. That said, I don't know what the current state of support for these less popular architectures is. The official page for platform support is https://forge.rust-lang.org/platform-support.html .

LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: http://lists.llvm.org/pipermail/llvm-dev/2016-November/10717...

That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

Post reply on HN