Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko <m dot ostapenko at samsung dot com>]

On 11/07/16 19:28, Jeff Law wrote:
> On 07/11/2016 10:08 AM, Maxim Ostapenko wrote:
> > On 11/07/16 18:05, Jakub Jelinek wrote:
> > > On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:
> > > > CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.
> >
> > Jakub, thanks for your summary.
> >
> > > I'm not convinced it is a good idea, that is why we've intentionally
> > > left it
> > > out when adding UBSan support, IMHO such an option defines 
> > > substantially
> > > different languages.
> >
> > The reason why I thought about -fsanitize=unsigned-integer-overflow
> > would be useful is that people still hit on undesired integer overflows
> > in their code (that may even lead to security vulnerabilities), despite
> > the fact some people intentionally rely on them.
> An integer overflow where the result feeds a malloc/alloca is 
> definitely a security issue.    There may be others.
>
> So one of the questions one might reasonably try to answer is can we 
> limit sanitization to those cases that are most likely going to be of 
> interest to developers. 

Thank you for your point. I think the easiest case here is pointer 
overflow (since we have a dedicated place where we construct 
POINTER_PLUS expression).
As for other cases, generally it's not easy to understand whether given 
binary expression is interesting or not. Of course, in some more or less 
trivial cases, such as
void foo (unsigned a, unsigned b)
{
    unsigned len = a + b;
    void *p = malloc (len);
}

we can make such decision, but in others, such as

void foo (unsigned len)
{
    ...................
    void *p = malloc (len);
}

void bar ()
{
    ...................
    unsigned len = a + b;
    foo (len);
}

we can't (and this is quite common code I believe). So, we can end up 
with missing some important cases.

> I suspect that in general integer overflow happens far often than 
> developers realize and that there'll be so many false positives that 
> the results will be ignored.

Yeah, even in small projects I observe a bunch of places where integer 
overflow happens. And yes, FPs are the real problem here...

> Jeff