This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 12/07/16 12:20, Yuri Gribov wrote:
On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
<> 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

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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]