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

11–20 of 504 posts

Re: Getting Past C

#11

Post by falcolas »

noselasd wrote: post #8
lacampbell wrote: post #7

> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

You can with fixed sized buffers; the size passed to read() would be constant.

I'd argue that for programs such as NTP, avoiding dynamic allocations on heap is not such a terrible goal.

Re: Getting Past C

#12

Post by jstewartmobile »

A 62 KLOC secure NTP server seems like an ideal project for this kind of experiment. I imagine it would be self-contained enough to actually use Rust or Golang instead of just treating them like FFI scripters.

Re: Getting Past C

#13

Post by lacampbell »

noselasd wrote: post #8
lacampbell wrote: post #7

> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

No.

It then follows that reading things safely is therefore a completely insurmountable problem in C. There is no possible way for me thin wrapper around read that works on bounds checked arrays, and not use "read" cavalierly in my code without thinking. Right?

Re: Getting Past C

#14

Post by falcolas »

IshKebab wrote: post #10
falcolas wrote: post #5

Earlier quoted context omitted.

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.

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 would benefit from using NTP.

Re: Getting Past C

#15

Post by civility »

noselasd wrote: post #8
lacampbell wrote: post #7

> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

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

Re: Getting Past C

#16

Post by tedunangst »

jerf wrote: post #6
falcolas wrote: post #2

How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures. Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?

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?)

Re: Getting Past C

#17

Post by [deleted] »

civility wrote: post #15
noselasd wrote: post #8

Earlier quoted context omitted.

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

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

[deleted]

Re: Getting Past C

#18

Post by leoedin »

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…

Microcontrollers aren't moving towards application level processors like the Raspberry Pi uses, they're moving towards low power ARM cores like the Cortex M0/M3/M4.

It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature. Current generation ARM Cortex M0 devices are available at a similar cost and with significant performance gains, with the benefit that if you realise you need a more powerful core you can scale up to hundreds of MHz with effectively the same code base.

Re: Getting Past C

#19

Post by TheAceOfHearts »

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.

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.

Re: Getting Past C

#20

Post by lacampbell »

civility wrote: post #15
noselasd wrote: post #8

Earlier quoted context omitted.

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

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 with built in bounds checking or anything else. This is more an argument against programming in a "close to the metal" language like C so thoughtlessly that buffer overflows are actually a serious issue.

Maybe you just need a pedantic mind. When first learning C, as soon as I figured out that writing "char buffer[BUFFER_LEN];" could cause your program to crash, I immediately set out to write a safe dynamic array implementation I could push chars onto it and I didn't have to worry. And I am by no means an expert C programmer.

Post reply on HN