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
