On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
<m.ostape...@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?
-Y
