linux-kernel - Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

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:   Thu, 22 Mar 2018 11:56:35 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Brian Norris <briannorris@...omium.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Leif Liddy <leif.linux@...il.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Daniel Drake <drake@...lessm.com>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome
 suspend/resume fix with a "rewritten" version

On Thu, Mar 22, 2018 at 06:52:51PM +0100, Greg Kroah-Hartman wrote:

[ ... ]
> 
> And that't the point to drive home here.  If you stay away from updating
> to stable patches, you have a huge boatload of KNOWN SECURITY HOLES in
> your product.  If you take them, you have the _possiblity_ of some bugs
> added, but overall, the rate is _VERY_ small.  Guenter has numbers of
> 2-4 patches per year cause problems.  That's lower than ANY other
> development model I have ever seen anywhere.
> 
Unfortunately, people tend to be irrational. Yes, the regression rate I have
observed is in the 0.1..0.15% range for v4.4.y and v4.14.y. Yet, there are
still people who believe that we should not merge stable releases due to the
regressions it causes (though they are much less vocal nowadays).

> So, stick with known buggy/insecure devices?  Or take the updates and
> handle the 1-2 problems a year they provide you.  I think the
> cost-analysis is easy to make here :)
> 

Agreed, on an objective basis. Unfortunately, one does not get credit for
fixing bugs which have never been observed in the field because they have
been fixed before they showed up. But one _does_ get blame for regressions.

Even though there have been very few regressions in absolute numbers, the
default reaction to newly observed problems is "it must be due to a stable
release merge", even though it almost always turns out to be incorrect.

The only way to deal with that is to reduce regressions to 0, or as close
to 0 as possible. 0.1% is good, but not good enough.

Also, while I agree that we are much better off in respect to security,
the verdict is still out if stable release merges actually improve release
stability; I don't see a clear trend even with chromeos-4.4. Of course,
it is all but impossible to say if this is due to 4.4.y or due to the
13,000+ patches we have on top of v4.4.y in chromeos-4.4.

Guenter