OSDev.org

alexfru wrote:

Brendan wrote: a) C is bad because it has too many rules that are not enforceable by the compiler

True. IOW, the compiler can help only so much with broken code.

Brendan wrote: b) GCC is bad because it doesn't detect or report "invalid input" where it could (C's rules that are enforceable by the compiler)

Like what? I know that several years ago it didn't warn about indexing an array with an invalid (too large) index in code something like "int a[10]; a[11] = 1;". I also know that it doesn't always spot things like "a[ i] = i++;" (a bit more complex expression will cause it miss the problem). What else?

alexfru wrote:

Brendan wrote: c) the combination of bad language and bad compiler unnecessarily increases the number of bugs and security vulnerabilities users are exposed to for no reason whatsoever

For a long time I thought it was mainly a problem of teaching/learning the language properly, of availability of good books and articles. The language is clearly much less intuitive than others, less well defined than assembly language / CPU architecture and makes math even more inhumane.

alexfru wrote:

Brendan wrote: d) this is probably the single largest "root cause" of security vulnerabilities

I'm not sure if it's the largest. You have to be pretty much in a paranoid mode when writing or fixing security-sensitive code. It's not a typical mindset/mode for most software developers. We also tend to overcomplicate things to the point at which it becomes hard to not miss an important edge case as such and not get overwhelmed by the amount of code we're dealing with. From my experience with Windows code I can tell that missing/insufficient/incorrect checks/validation were around the top issues implementation-wise. Even decent C/C++ coders from time to time will forget to check this or that.

    int saturatingAdd(int a, int b) {
        if(a + b > INT_MAX) return INT_MAX;
        if(a + b < INT_MIN) return INT_MIN;
        return a + b;
    }

alexfru wrote:

Brendan wrote: e) with a better language and better compiler the majority of security vulnerabilities could've been avoided without any significant disadvantages

You'd have to trade some performance to make C well/better defined.

Rusky wrote:Assuming integers do not overflow is actually pretty important for loop optimizations, so barring some other changes to the type system, defining it would actually make it slower.

Rusky wrote:That's what I said- several important loop optimizations rely on integers not overflowing (array indices and otherwise).

• Don't use signed integers in the first place
• Do use signed integers but it can be proven that the integer doesn't overflow anyway
• Do use signed integers, but these hypothetical optimisations still work
• Do use signed integers, but the integer/s are used for array indexes and therefore the compiler can assume they don't overflow regardless

Rusky wrote:As far as examples go, I have to admit I don't know enough to say. It does seem important enough to the GCC maintainers that they added -fno-strict-overflow in addition to -fwrapv, specifically to inhibit the optimizer in fewer situations: http://www.airs.com/blog/archives/120

Brendan wrote:

alexfru wrote:

Brendan wrote: c) the combination of bad language and bad compiler unnecessarily increases the number of bugs and security vulnerabilities users are exposed to for no reason whatsoever

For a long time I thought it was mainly a problem of teaching/learning the language properly, of availability of good books and articles. The language is clearly much less intuitive than others, less well defined than assembly language / CPU architecture and makes math even more inhumane.

I used to think it was mostly a problem with the programmers too (and in some cases it is). However; people with far more experience using C than I'll (hopefully) ever have are still creating the same bugs as everyone else. Mostly, it's easy to write code in C that "seems to work" that doesn't comply with the language's specification and has subtle bugs that might not be noticed for 10+ years even if/when hundreds of C programmers look at the code.

Brendan wrote:

alexfru wrote:

Brendan wrote: d) this is probably the single largest "root cause" of security vulnerabilities

I'm not sure if it's the largest. You have to be pretty much in a paranoid mode when writing or fixing security-sensitive code. It's not a typical mindset/mode for most software developers. We also tend to overcomplicate things to the point at which it becomes hard to not miss an important edge case as such and not get overwhelmed by the amount of code we're dealing with. From my experience with Windows code I can tell that missing/insufficient/incorrect checks/validation were around the top issues implementation-wise. Even decent C/C++ coders from time to time will forget to check this or that.

It's much worse than that. For a simple test, see if you can write a 100% correct/valid version of this code:

Code: Select all

    int saturatingAdd(int a, int b) {
        if(a + b > INT_MAX) return INT_MAX;
        if(a + b < INT_MIN) return INT_MIN;
        return a + b;
    }

I'd be willing to bet that over half of the experienced/professional C programmers will end up with subtle bugs; especially if they're writing the code as part of their normal work and don't know it's a test/challenge.

    signed char saturatingAdd(signed char a, signed char b) {
        if(a + b > SCHAR_MAX) return SCHAR_MAX;
        if(a + b < SCHAR_MIN) return SCHAR_MIN;
        return a + b;
    }

    uint32_t mul32_16x16(uint16_t a, uint16_t b) {
        return a * b;
    }

    uint32_t ReadAsLittleEndian32(uint8_t* p) {
        return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
    }

    size_t bufsz, item1sz, item2sz, item3sz;

    // get the sizes into the above variables

    if (item1sz + item2sz + item3sz > bufsz)
    {
        // error handling
    }

    // copy all items into the buffer

alexfru wrote:

Brendan wrote:It's much worse than that. For a simple test, see if you can write a 100% correct/valid version of this code:

Code: Select all

    int saturatingAdd(int a, int b) {
        if(a + b > INT_MAX) return INT_MAX;
        if(a + b < INT_MIN) return INT_MIN;
        return a + b;
    }

I'd be willing to bet that over half of the experienced/professional C programmers will end up with subtle bugs; especially if they're writing the code as part of their normal work and don't know it's a test/challenge.

That's probably a bad example. I wouldn't call anyone an experienced/professional C programmer if they wrote the above piece of code. Because it shows two basic problems and doesn't even touch trickier and more interesting things.

alexfru wrote:And the below variant for signed chars could have a chance to work:

Code: Select all

    signed char saturatingAdd(signed char a, signed char b) {
        if(a + b > SCHAR_MAX) return SCHAR_MAX;
        if(a + b < SCHAR_MIN) return SCHAR_MIN;
        return a + b;
    }

alexfru wrote:While everything looks fine at first glance, most likely there's a UB hiding in plain sight.

Combuster wrote:Just for the sake of trying (not tested at all):

Code: Select all

int saturateAdd(int a, int b)
{
    if ((b > 0) && (INT_MAX - b < a)) return INT_MAX;
    if ((b < 0) && (INT_MIN - b > a)) return INT_MIN;
    return a+b;
}

Brendan wrote:

alexfru wrote: That's probably a bad example. I wouldn't call anyone an experienced/professional C programmer if they wrote the above piece of code. Because it shows two basic problems and doesn't even touch trickier and more interesting things.

I know it's buggy - the question is whether people can be expected to write a correct version. So far, nobody has had the courage to attempt this extremely simple piece of code.

Brendan wrote:

alexfru wrote:And the below variant for signed chars could have a chance to work:

Code: Select all

    signed char saturatingAdd(signed char a, signed char b) {
        if(a + b > SCHAR_MAX) return SCHAR_MAX;
        if(a + b < SCHAR_MIN) return SCHAR_MIN;
        return a + b;
    }

You've tried to avoid problems by using signed char instead of int; but even in that case are you sure your code is correct in all cases? Hint: Imagine a computer (maybe a DSP) where CHAR_BITS == 32, and where sizeof(int) == sizeof(long) == 1.

Brendan wrote:

alexfru wrote:While everything looks fine at first glance, most likely there's a UB hiding in plain sight.

Exactly. People (experienced C programmers) can't be expected to do trivial things in C correctly because the language itself makes it virtually impossible; and the only reason anything larger/more complex works is because everyone relies on "seems to work despite being technically wrong" (including relying on both undefined behaviour and implementation defined behaviour).

willedwards wrote: When the time comes I will push for LLVM and GCC builtins for saturating arithmetic, in line with the recent alignment on overflow: http://clang.llvm.org/docs/LanguageExte ... c-builtins