linux-kernel - Re: [Patch v4 2/2] linux/bits.h: Add compile time sanity check of GENMASK inputs

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]

Date:   Fri, 1 Nov 2019 22:28:57 +0100
From:   Rikard Falkeborn <rikard.falkeborn@...il.com>
To:     Rikard Falkeborn <rikard.falkeborn@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, bp@...en8.de,
        joe@...ches.com, johannes@...solutions.net, keescook@...omium.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
        yamada.masahiro@...ionext.com,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Haren Myneni <haren@...ibm.com>
Subject: Re: [Patch v4 2/2] linux/bits.h: Add compile time sanity check of
 GENMASK inputs

On Tue, Oct 22, 2019 at 09:53:06PM +0200, Rikard Falkeborn wrote:
> On Fri, Oct 11, 2019 at 07:27:37PM -0700, Andrew Morton wrote:
> > On Wed,  9 Oct 2019 23:45:02 +0200 Rikard Falkeborn <rikard.falkeborn@...il.com> wrote:
> > 
> > > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > > as the first argument and the low bit as the second argument. Mixing
> > > them will return a mask with zero bits set.
> > > 
> > 
> > I'm seeing some breakage in code which is newly added in linux-next:
> > 
> 
> As of next-20191021, those breakages are fixed ([0], [1]). next-20191021
> now builds (at least for x86-64) with the GENMASK compile checks added.
> 
> I also stumbled upon [2], which is a fix for an unused macro in a header
> in mips/include/asm. next-201008 contained both v3 of this patch and the
> mips header with the bad GENMASK in without build regressions, so it
> *should* be ok to include v4 (but given the track record of this patch,
> I totally understand if you want to wait until [2] lands in mips-next and
> linux-next).
> 
> Rikard
> 
> [0]: https://lore.kernel.org/patchwork/patch/1139777/
> [1]: https://lore.kernel.org/patchwork/patch/1139778/
> [2]: https://lore.kernel.org/linux-mips/20191022192547.480095-1-rikard.falkeborn@gmail.com/T/#u

And as of next-20191031, the mentioned mips-header is fixed [0]. Also, a
recently introduced arm-bug has also been fixed. I just built x86-64 and
arm64 allmodconfigs without issue.

Trying to get this patch merged feels a bit like playing whack a-mole.
Perhaps it would have been better to make it a warning at first, and
then promote the warning to an error in a later release? Then everyone
would have the warning in their tree when they do development and the
number if issues in next would be (almost) zero.

Rikard

[0]: https://lore.kernel.org/linux-mips/20191009013721.qda2bo5teppr7nom@pburton-laptop/T/#m6e7cd9c89ef06240fe3cd36a60bd73eff1a1ea5d
[1]: https://www.spinics.net/lists/arm-kernel/msg764473.html