linux-kernel - Re: mmotm 2020-01-23-21-12 uploaded (efi)

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAKv+Gu8ZRjqvQvOJ5JXpAQXyApMQNAFz7cRO9NSjq9u=WnjkTA@mail.gmail.com>
Date:   Tue, 28 Jan 2020 08:33:45 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Qian Cai <cai@....pw>, Randy Dunlap <rdunlap@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mark Brown <broonie@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Michal Hocko <mhocko@...e.cz>, mm-commits@...r.kernel.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Ard Biesheuvel <ardb@...nel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: mmotm 2020-01-23-21-12 uploaded (efi)

On Tue, 28 Jan 2020 at 07:26, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Tue, Jan 28, 2020 at 7:15 AM Qian Cai <cai@....pw> wrote:
> > > Should be fixed by
> > >
> > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/
> >
> > Cc kasan-devel@
> >
> > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler?
>
> My understanding is that this is invalid C code in the first place,
> no? It just happened to compile with some compilers, some options and
> probably only with high optimization level.

No, this is not true. The whole point of favoring IS_ENABLED(...) over
#ifdef ... has always been that the code remains visible to the
compiler, regardless of whether the option is selected or not, but
that it gets optimized away entirely. The linker errors prove that
there is dead code remaining in the object files, which means we can
no longer rely on IS_ENABLED() to work as intended.

> There is a known, simple fix that is used throughout the kernel -
> provide empty static inline stub, or put whole calls under ifdef.

No, sorry, that doesn't work for me. I think it is great that we have
diagnostic features that are as powerful as KASAN, but if they require
code changes beyond enable/disable, I am not going to rely on them.