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

31–40 of 504 posts

Re: Getting Past C

#31

Post by qznc »

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…

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

Re: Getting Past C

#32

Post by strictfp »

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 noone ever does that? Or at the very least people don't think of that as idiomatic c.

Re: Getting Past C

#33

Post by JKCalhoun »

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…

Or perhaps just some helper functions in C that wrap array and pointer allocation/access to provide sanity checks. Seems like moving to a new language is rather extreme....

Re: Getting Past C

#34

Post by civility »

munin wrote: post #26
lacampbell wrote: post #20

Earlier quoted context omitted.

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?

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

It will cost a single correctly predicted branch, which is effectively free on modern architectures. Any "safe" language will have to make this conditional branch too (Rust's File::read method will check the size of the slice).

Re: Getting Past C

#35

Post by naasking »

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…

> 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/buffer abstraction and use it in your C programs that abort on invalid indexing. Now how many actually do this? Very few given the prevalence of C programs on vulnerability disclosure lists.

Re: Getting Past C

#36

Post by lossolo »

naasking wrote: post #35
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…

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

Re: Getting Past C

#37

Post by tedunangst »

qznc wrote: post #31
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…

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

As others have noted, one can also write a four line saferead() function.

Re: Getting Past C

#38

Post by falcolas »

leoedin wrote: post #18
falcolas wrote: post #14

Earlier quoted context omitted.

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 y…

I'd love to read more about this microcontroller migration towards ARM - any hints on where to look?

Re: Getting Past C

#39

Post by dragontamer »

leoedin wrote: post #18
falcolas wrote: post #14

Earlier quoted context omitted.

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 y…

I dunno of many Cortex M0+ devices that can source/sink 40mA like an AVR while only sipping 200uA (microAmps) like the AtMega328pb. That's active mode btw, AtMega328pb drops down to 1.3 uA in sleep mode.

Cortex M0+ devices are "larger" than AVRs. You have more RAM, CPU power and unfortunately... complexity and power usage.

I'm thinking a good example is the LPC811 from NXP: very good specs and it really shows how good ARM M0+ systems have become: http://www.nxp.com/documents/data_sheet/LPC81XM.pdf

But its still got an order of magnitude more power usage and complexity over AVR's AtMega328pb. The ATMega's "active" mode is comparable to the LPC811's "sleep" mode.

Most of the LPC811's pins only can sink / source ~4mA, while the "biggest" pins can only sink / source 20mA. In contrast, all of the AtMega328pb pins can sink/source 40mA. Easily driving LEDs with only a resistor (instead of having to hook up a transistor or external buffer of some kind)

The LPC811 also shows what happens to cheap ARM chips: they are missing ADC converters, PWM, Real-time Counters (or a deep-sleep mode that still keeps the 32kHz clock active). Sure, you can buy these externally... but the AVRs and PICs have superior integration.

> It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature.

Running an LED with just a resistor on any pin is a pretty nifty feature IMO.

------------

The AtMega328pb is a "bigger" and more expensive part though. Perhaps its more "fair" to compare the LPC811 against the AtTiny44A (which is also $1.50ish). ATTiny44A has similar power specifications as the 328pb.

Re: Getting Past C

#40

Post by staticassertion »

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 using the 'unsafe' keyword.

let v = vec![0, 1, 2]; unsafe { let x = v.get_unchecked(5); }

This means you can basically grep audit for vulnerabilities, and the above code should be very rare.

Post reply on HN