Re: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds)

From: Oliver Pinter <oliver.pntr_at_gmail.com>
Date: Thu, 19 Dec 2013 12:38:28 +0100
On 12/19/13, Stefan Esser <se_at_freebsd.org> wrote:
> Am 30.11.2013 14:56, schrieb Konstantin Belousov:
>> I propose to unconditionally add the switch  -fno-strict-overflow
>> to the kernel compilation.  See the patch at the end of message for
>> exact change proposed.
>>
>> What does it do. It disallows useless and counter-intuitive
>> behaviour of the compiler(s) for the signed overflow. Basically,
>> the issue is that the C standard left signed overflow as undefined
>> to allow for different hardware implementation of signess to be
>> used for signed arithmetic. De-facto, all architectures where
>> FreeBSD works or have a chance to be ported, use two-complement
>> signed integer representation, and developers intuition is right
>> about it.
>>
>> The compiler authors take the undefined part there as a blanket to
>> perform optimizations which are assuming that signed overflow
>> cannot happen.  The problem with that approach is that typical
>> checks for bounds are exactly the place where the overflow can
>> happen.  Instead of making some artificial example, I would just
>> point to my own r258088 and r258397.
>>
>> What makes the things much worse is that the behaviour is highly
>> depended on the optimization level of the exact version of
>> compiler.
>>
>> What other projects did in this regard. They turned the same knob
>> unconditionally. I can point at least to Linux kernel and
>> Postgresql. Python uses -fwrapv, which is equivalent to the
>> -fno-strict-overflow on the two-complement machines.  Linux used
>> -fwrapv before switched to -fno-strict-overflow.
>
> Hi Konstantin,
>
> you may put back -fno-strict-overflow after I found and fixed the
> problem uncovered by enabling it in -CURRENT (SVN rev. 259609).
>
> The problem was an overflow in the conversion of timeout values to
> sbintine, which lead to negative values being detected with
> -fno-strict-overflow, while the compiler performed the signedness
> test before the multiplication, without that option.
>
> I found that timeout values of more than 1000 years were requested
> by some programs, which are now capped at 68 years (the maximum that
> can be represented by sbintime, 2^31 seconds).
>
> So, -fno-strict-overflow has already proved itself to be useful
> in uncovering a bug that would have been hard to find, otherwise.
>

I have a plan, to port this or like this plugin to llvm/clang in the
near future:

http://www.grsecurity.net/~ephox/overflow_plugin/

> Regards, STefan
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Thu Dec 19 2013 - 10:38:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:45 UTC