Re: MIT discovered issue with gcc

[Joe Pfeiffer <pfeiffer@cs.nmsu.edu>]

Robert Baron <robertbartlettbaron@gmail.com> writes:

> Aren't many of the  constructs used as examples in the paper are commonly used
> in c programming.  For example it is very common to see a function that has a
> pointer as a parameter defined as:
>
> int func(void *ptr)
>     {
>     if(!ptr) return SOME_ERROR;
>     /* rest of function*/
>     return 1;
>     }
>
> Isn't it interesting that their one example will potentially dereference the
> null pointer even before compiler optimizations (from the paper):
>
> struct tun_struct *tun=....;
> struct sock *sk = tun->sk;
> if(*tun) return POLLERR; 
>
> The check to see that tun is non-null should occur before use, as in - quite
> frankly it is useless to check after as tun cannot be the null pointer (the
> program hasn't crashed):
>
> struct tun_struct *tun=....;
> if(*tun) return POLLERR; 
> struct sock *sk = tun->sk;

The paper points out that the code contains a bug; the claim in the
paper is that it is a minor bug as written (it only gets past the
tun->sk dereference if page 0 has somehow been made readable), but
becomes a possible privilege escalation after the check has been
optimized away.

> I am under the impression that these problems are rather widely known among c
> programmers (perhaps not the kids fresh out of college).  But this is why
> teams need to have experienced people. 
>
> Furthermore, it is very common to find code that works before optimization,
> and fails at certain optimization levels.  Recently, I was compiling a library
> that failed its own tests under the optimization level set in the makefile but
> passed its own test at a lower level of optimization.

Isn't that, and an analysis of when this can happen, the main point of
the paper?