Message-ID: <a841536fe65bb33f1c72ce2455a6eb47a0107565.camel@HansenPartnership.com>
Date:   Tue, 24 Nov 2020 23:05:35 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Joe Perches <joe@...ches.com>,
        Jakub Kicinski <kuba@...nel.org>, alsa-devel@...a-project.org,
        linux-atm-general@...ts.sourceforge.net,
        reiserfs-devel@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-wireless@...r.kernel.org, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Nathan Chancellor <natechancellor@...il.com>,
        linux-ide@...r.kernel.org, dm-devel@...hat.com,
        keyrings@...r.kernel.org, linux-mtd@...ts.infradead.org,
        GR-everest-linux-l2@...vell.com, wcn36xx@...ts.infradead.org,
        samba-technical@...ts.samba.org, linux-i3c@...ts.infradead.org,
        linux1394-devel@...ts.sourceforge.net,
        linux-afs@...ts.infradead.org,
        usb-storage@...ts.one-eyed-alien.net, drbd-dev@...ts.linbit.com,
        devel@...verdev.osuosl.org, linux-cifs@...r.kernel.org,
        rds-devel@....oracle.com,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-scsi@...r.kernel.org, linux-rdma@...r.kernel.org,
        oss-drivers@...ronome.com, bridge@...ts.linux-foundation.org,
        linux-security-module@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org,
        linux-stm32@...md-mailman.stormreply.com, cluster-devel@...hat.com,
        linux-acpi@...r.kernel.org, coreteam@...filter.org,
        intel-wired-lan@...ts.osuosl.org, linux-input@...r.kernel.org,
        Miguel Ojeda <ojeda@...nel.org>,
        tipc-discussion@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
        linux-media@...r.kernel.org, linux-watchdog@...r.kernel.org,
        selinux@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org, linux-geode@...ts.infradead.org,
        linux-can@...r.kernel.org, linux-block@...r.kernel.org,
        linux-gpio@...r.kernel.org, op-tee@...ts.trustedfirmware.org,
        linux-mediatek@...ts.infradead.org, xen-devel@...ts.xenproject.org,
        nouveau@...ts.freedesktop.org, linux-hams@...r.kernel.org,
        ceph-devel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-arm-kernel@...ts.infradead.org, linux-hwmon@...r.kernel.org,
        x86@...nel.org, linux-nfs@...r.kernel.org,
        GR-Linux-NIC-Dev@...vell.com, linux-mm@...ck.org,
        netdev@...r.kernel.org, linux-decnet-user@...ts.sourceforge.net,
        linux-mmc@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-sctp@...r.kernel.org, linux-usb@...r.kernel.org,
        netfilter-devel@...r.kernel.org, linux-crypto@...r.kernel.org,
        patches@...nsource.cirrus.com, linux-integrity@...r.kernel.org,
        target-devel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for
 Clang

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James

Powered by blists - more mailing lists