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

21–30 of 504 posts

Re: Getting Past C

#21

Post by binarycrusader »

tedunangst wrote: post #16
jerf wrote: post #6

Earlier quoted context omitted.

In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so. Also, it has been suggested by some experiences that o…

I'm never quite sure where MIPS and SPARC are in terms of llvm support. (And does llvm support automatically mean rust support?)

LLVM is generally usable on sparc, although a significant amount of optimisation work still needs to be done, and there are some specific variants/platforms that sparc is used by that need better support.

Re: Getting Past C

#22

Post by tptacek »

This is literally the only thing I can think of that "NTPsec" can do that would result in the project having any relevance. I understand why some very specific sites are chained to the ntpd codebase, but the vast, overwhelming majority of the ntpd deployed base not only isn't tied to ntpd, but also doesn't need 99% of what ntpd does. Trying to "secure" that codebase always seemed to me like a very silly windmill to tilt at.

Re: Getting Past C

#23

Post by topspin »

falcolas wrote: post #5
squiguy7 wrote: post #3

Earlier quoted context omitted.

Rust has impressive support for different architectures. I ran `rustc --print target-list` and it returned 63.

That includes one line per architecture / platform (i.e. OS) combination. I only count about 14 architectures, though my rustc is old (GCC has 23 major, 24 minor, and 30 legacy as a point of comparison). Last I checked, some of the popular IOT architectures (atmega, etc) were not included without some 3rd party plugins.

>> though my rustc is old

I just counted on nightly and got 20 distinct architectures, including all the le variants; every distinct architecture value, iow.

Re: Getting Past C

#24

Post by falcolas »

TheAceOfHearts wrote: post #19
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.

If it's a business requirement, they should hire engineers and contribute. Expecting free support seems unreasonable. There's a high cost for supporting and maintaining features, so somebody ends up having to pay for it.

To be fair, I imagine most of those arch manufacturers simply think "embedded developers use C, we support C, job done."

LLVM support would benefit the developers more, but they have their own budgets and constraints, which are probably not conducive to submitting and maintaining a LLVM plugin.

Re: Getting Past C

#25

Post by pklausler »

Honestly, why not do it once and for all in a strongly typed pure functional language, validate it, and then tweak the GC parameters to get the performance? Use the safest and most powerful language that you can, if you can.

Re: Getting Past C

#26

Post by munin »

lacampbell wrote: post #20
civility wrote: post #15

Earlier quoted context omitted.

I'll bet he can give you an array_read() function that does what you ask. I know I could.

The fact that it doesn't occur to people to build safe abstractions in C to deal with things like buffer overflows still shocks me. C is fairly low level by todays standards. You 100% have to build abstractions using the standard library and then use those abstractions, rather than just using standard library functions everywhere. This isn't an argument against safer languages, or higher level languages, or languages…

Is this abstraction zero-cost? What's the overhead?

Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What is the cost of that abstraction? How does it compare to a runtime's GC?

Re: Getting Past C

#27

Post by dreta »

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 when trying to work with memory in Rust.

Re: Getting Past C

#28

Post by cesarb »

tedunangst wrote: post #16
jerf wrote: post #6

Earlier quoted context omitted.

In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so. Also, it has been suggested by some experiences that o…

I'm never quite sure where MIPS and SPARC are in terms of llvm support. (And does llvm support automatically mean rust support?)

No, LLVM support does not automatically mean Rust support, though it's a prerequisite for it. There are several small things which have to be defined in the Rust compiler. For instance, which registers are used for stack unwinding, and other ABI details.

Re: Getting Past C

#29

Post by kelnos »

falcolas wrote: post #9
jerf wrote: post #6

Earlier quoted context omitted.

In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so. Also, it has been suggested by some experiences that o…

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.

I expect that most of these older devices don't receive much in the way of software updates anyway, so the point is moot. For things that do receive updates, I would much rather see a secure NTP implementation that the majority of the world can use, even if a few parts of the long tail get excluded... and they still have the old versions of the C-based NTPsec they can use; I would also expect there to be a niche market arising for releasing security updates to it after the transition.

(Specifically addressing IoT devices, IoT security is so abysmal in general that there are much easier ways to compromise one than targeting its NTP daemon, if it's even running one, and if it's even "bothering" to run a secure one like NTPsec.)

Dropping support for things is certainly not a decision you make lightly, but sometimes the greater good demands it.

Re: Getting Past C

#30

Post by civility »

lacampbell wrote: post #20
civility wrote: post #15

Earlier quoted context omitted.

I'll bet he can give you an array_read() function that does what you ask. I know I could.

The fact that it doesn't occur to people to build safe abstractions in C to deal with things like buffer overflows still shocks me. C is fairly low level by todays standards. You 100% have to build abstractions using the standard library and then use those abstractions, rather than just using standard library functions everywhere. This isn't an argument against safer languages, or higher level languages, or languages…

Completely agree. The same is true at a slightly higher level in C++. All of the "dangling reference" problems can be avoided by using a value-based collection library and not creating references. Then upgrade to a unique or shared pointer when copying values is too expensive.
Post reply on HN