lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 2 Nov 2018 16:17:23 +0300
From:   Andrey Ryabinin <>
To:     Linus Torvalds <>,
        Miguel Ojeda <>
        Konstantin Ryabitsev <>,
        David Miller <>,
        Kees Cook <>,,
        Ingo Molnar <>,,,,
        David Woodhouse <>,,
        Philippe Ombredanne <>,,,,,,
        Jonathan Corbet <>,
        Theodore Ts'o <>,
        Geert Uytterhoeven <>,
        Rasmus Villemoes <>,,
        Arnd Bergmann <>,,,,
        Nick Desaulniers <>,
        Andrew Morton <>,
        Greg KH <>,,,,
Subject: Re: [GIT PULL] Compiler Attributes for v4.20-rc1

On 11/02/2018 04:46 AM, Linus Torvalds wrote:
> On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds
> <> wrote:
>> The logic for using __no_sanitize_address *used* to be
>>     #if GCC_VERSION >= 40902
> Ok, looking around, I think this has less to do with the attribute
> being recognized, and simply just being because KASAN itself wants
> gcc-4.9.2.
> I'm actually not seeing that KASAN dependency in the Kconfig scripts
> (and it probably _should_ be now that we can just add compiler version
> dependencies there), but that explains why the gcc version check is
> different from "gcc supports the attribute".
> Anyway, I decided to do the merge by just getting rid of the
> GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
> you enable KASAN, then a function with that marking just won't be
> marked inline.
> End result: pulled. I'm as confused as you are as to why
> __no_sanitize_address_or_inline is in the gcc header, but I guess it
> ends up being the same issue: KASAN depends on gcc even if that
> dependency doesn't seem to be spelled out in lib/Kconfig.kasan.
> So I _think_ the KASAN config should have a
>     depends on CC_IS_GCC && GCC_VERSION >= 40902
> on it, but maybe there is something I'm missing.

I'd rather use cc-option instead of version check, since we also support clang.

It should be possible to express compiler requirements for subfeatures
like stack/inline instrumentation in Kconfig. But that would be not that trivial, 
see the scripts/Makefile.kasan

> But from a pull standpoint, I don't want to mess with those
> (unrelated) issues, so I just kept the merge resolution as simple and
> straightforward as possible.
> Miguel, please do double-check the merge (it's not pushed out yet, I'm
> doing the usual build tests etc first).
>                     Linus

Powered by blists - more mailing lists