On Fri, Sep 15, 2023 at 11:43 AM Kees Cook via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> 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.
Yes, I believe combining A and B should be allowed.
> > >> 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
I see a Clang patch that proposes -fsanitize=signed-integer-wrap,
which appears to be the same as signed-integer-overflow, but performs
the check in the -fwrapv mode.
I made a reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317#c13 that we
probably should just make -fsanitize=signed-integer-overflow work with
-fwrapv.
(This message is made so that interested folks are informed of the
Clang change.)
--
宋方睿
