Neverflow: C macros that guard against buffer overflows
1–10 of 150 posts
Re: Neverflow: C macros that guard against buffer overflows
#2Never heard of a serious buffer overflow caused by _constant_ indices. Does it work with AT(arr, i), or only with AT(arr, 10)?
Re: Neverflow: C macros that guard against buffer overflows
#3Never heard of a serious buffer overflow caused by _constant_ indices. Does it work with AT(arr, i), or only with AT(arr, 10)?
Yeap, that's the whole point of it
Re: Neverflow: C macros that guard against buffer overflows
#4Runtime bounds check tied to fprintf and abort via macros. Allocation by calloc.
Re: Neverflow: C macros that guard against buffer overflows
#5Interesting idea, although given the demotion into optional feature in C11, it isn't necessarly portable.
Also doesn't cover all the string and memory buffer manipulations.
SAL and Frama-C are the bare minimum for security in C code.
Re: Neverflow: C macros that guard against buffer overflows
#6Never heard of a serious buffer overflow caused by _constant_ indices. Does it work with AT(arr, i), or only with AT(arr, 10)?
Yeap, that's the whole point of it
Huh I misinterpreted the error messages in the example, I thought those were compiler output. This is quite cool then.
EDIT: although, it seems like this looses much of its power once you start passing these buffers around to functions that do not use these macros.
Re: Neverflow: C macros that guard against buffer overflows
#7Never heard of a serious buffer overflow caused by _constant_ indices. Does it work with AT(arr, i), or only with AT(arr, 10)?
"'Brother,' says he, 'greetings. Didn't I see you in Southern Missouri last summer selling colored sand at half-a-dollar a teaspoonful to put into lamps to keep the oil from exploding?'
"'Oil,' says I, 'never explodes. It's the gas that forms that explodes.' But I shakes hands with him, anyway.
...
"'Listen,' says I. 'I instruct her to keep her lamp clean and well filled. If she does that it can't burst. And with the sand in it she knows it can't, and she don't worry.
— O. Henry, The Man Higher Up
Re: Neverflow: C macros that guard against buffer overflows
#8The problem with C and buffer overflows isn't that you can't guard against them, or that there is no existing, reusable code to do so — it's that none of this functionality is standardized. Adding another one to the existing 41383 ways of doing this is in fact the exact opposite of what's needed. Ideally C needs one way of doing this, and that would be described in the standard.
But that's not how C "rolls", and we'll never get that. So I guess we now have 41384 ways to do buffer overflow guards.
Re: Neverflow: C macros that guard against buffer overflows
#9Interesting idea, although given the demotion into optional feature in C11, it isn't necessarly portable. Also doesn't cover all the string and memory buffer manipulations. SAL and Frama-C are the bare minimum for security in C code.
Frama-C as a bare minimum is a pipe dream.
It's a nice thought, don't get me wrong, but it's hard enough to convince people to add `-fsanitize=...` to their compiler flags. An entire separate static analysis tool with its own learning curve (and its own set of idiosyncrasies) doesn't really qualify for "bare minimum" IMO.
Re: Neverflow: C macros that guard against buffer overflows
#10Runtime bounds check tied to fprintf and abort via macros. Allocation by calloc.
The calloc part is one of the most common blind spots I see among C programmers.
I try to avoid the malloc(n * sizeof (...)) pattern as much as possible. Sure there are lots of cases where it can never overflow, and you might save a bit of overhead from the zeroing and overflow checking, but most of that overhead might also be imaginary depending on allocator internals, and even kernel internals. It's the sort of thing it only makes sense to optimise when you've already squeezed out every bit of performance. And by then you've probably minimised dynamic allocation as much as possible anyway.
It's also very easy to think something like "well, n is passed in as a parameter, but it's a static function, and I know all the callers. So it's fine".
But now every caller in the future has to be aware of this possibility.