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

[Maxim Ostapenko]

On 12/07/16 12:20, Yuri Gribov wrote:
> On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
> <m.ostapenko@samsung.com> wrote:
>> 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...
> There are people who would tolerate FPs if the tool indeed helps to
> find vulnerabilities. Especially if there is easy way to suppress
> checks in set of functions/files who intentionally rely on unsigned
> overflow (hash functions, etc.).
>
> What are the FP rates you see with current version of the patch?

A lot... this depends of particular project. Say, GCC has so much code 
that essentially relies on unsigned integer overflows, that I can't even 
tell you a ratio.
For, Firefox I saw ~90% of FP ratio (given the fact I use several hacks 
in GCC to reduce this ratio), they are mostly come from hashing code and 
MULT expressions.

>
> -Y
>
>