On Fri, Sep 15, 2023 at 05:47:08PM +0000, Qing Zhao wrote: > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener <richard.guent...@gmail.com> > > wrote: > > > > > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao <qing.z...@oracle.com>: > >> > >> > >> > >>>> On Sep 15, 2023, at 11:29 AM, Richard Biener > >>>> <richard.guent...@gmail.com> wrote: > >>>> > >>>> > >>>> > >>>>> Am 15.09.2023 um 17:25 schrieb Qing Zhao <qing.z...@oracle.com>: > >>>> > >>>> > >>>> > >>>>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović <ar...@aarsen.me> wrote: > >>>>> > >>>>> > >>>>> Qing Zhao <qing.z...@oracle.com> writes: > >>>>> > >>>>>> Even though unsigned integer overflow is well defined, it might be > >>>>>> unintentional, shall we warn user about this? > >>>>> > >>>>> This would be better addressed by providing operators or functions that > >>>>> do overflow checking in the language, so that they can be explicitly > >>>>> used where overflow is unexpected. > >>>> > >>>> Yes, that will be very helpful to prevent unexpected overflow in the > >>>> program in general. > >>>> However, this will mainly benefit new codes. > >>>> > >>>> For the existing C codes, especially large applications, we still need > >>>> to identify all the places > >>>> Where the overflow is unexpected, and fix them. > >>>> > >>>> One good example is linux kernel. > >>>> > >>>>> One could easily imagine a scenario > >>>>> where overflow is not expected in some region of code but is in the > >>>>> larger application. > >>>> > >>>> Yes, that’s exactly the same situation Linux kernel faces now, the > >>>> unexpected Overflow and > >>>> expected wrap-around are mixed together inside one module. > >>>> It’s hard to detect the unexpected overflow under such situation based > >>>> on the current GCC. > >>> > >>> But that’s hardly GCCs fault nor can GCC fix that in any way. Only the > >>> programmer can distinguish both cases. > >> > >> Right, compiler cannot fix this. > >> But can provide some tools to help the user to detect this more > >> conveniently. > >> > >> Right now, GCC provides two set of options for different types: > >> > >> A. Turn the overflow to expected wrap-around (remove UB); > >> B. Detect overflow; > >> > >> A B > >> remove UB -fsanitize=… > >> signed -fwrapv signed-integer-overflow > >> pointer -fwrapv-pointer pointer-overflow (broken in Clang) > >> > >> However, Options in A and B excluded with each other. They cannot mix > >> together for a single file. > >> > >> What’s requested from Kernel is: > >> > >> compiler needs to provide a functionality that can mix these two together > >> for a file. > >> > >> i.e, apply A (convert UB to defined behavior WRAP-AROUND) only to part of > >> the program. And then add -fsnaitize=*overflow to detect all other > >> Unexpected overflows in the program. > >> > >> This is currently missing from GCC, I guess? > > > > How can GCC know which part of the program wants wrapping and which > > sanitizing? > > GCC doesn’t know, but the user knows. > > Then just provide the user a way to mark part of the program to be wrapping > around and excluded from sanitizing? > > Currently, GCC provides > > __attribute__(optimize ("wrapv")) > > To mark the specific function to be wrapped around. > > However, this attribute does not work for linux kernel due to the following > reason: > > Attribute optimize should be only used for debugging purpose; > The kernel has banned its usage; > > So, a new attribute was requested from Linux kernel security: > > request wrap-around behavior for specific function (PR102317) > __attribute__((wrapv)) > > Is this request reasonable?
After working through this discussion, I'd say it's likely more helpful to have a way to disable the sanitizers for a given function (or variable). i.e. The goal for the kernel would that untrapped wrap-around would be the very rare exception. e.g. our refcount_t implementation: https://elixir.bootlin.com/linux/v6.5/source/include/linux/refcount.h#L200 Then we can continue to build the kernel with -fno-strict-overflow (to avoid UB), but gain sanitizer coverage for all run-time wraps, except for the very few places where we depend on it. Getting there will also take some non-trivial refactoring on our end, but without the sanitizers we're unlikely to find them all. -- Kees Cook