Cc John.
On Tue, Jul 12, 2016 at 10:49 AM, Maxim Ostapenko
<m.ostape...@samsung.com> wrote:
> On 12/07/16 12:20, Yuri Gribov wrote:
>>
>> 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?
>
>
> 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
>>
>>
>
