linux-kernel - Re: [GIT PULL] x86 PTI and Spectre related fixes and updates

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Feb 2018 09:16:46 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andy Lutomirski <luto@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [GIT PULL] x86 PTI and Spectre related fixes and updates

* Ingo Molnar <mingo@...nel.org> wrote:

> > > This is not a complaint so much as a "is it worth it?" question..
> > 
> > So far, I think this is the first conflict it's generated in a long
> > time, so previously it was worth it from my point of view.  As long as
> > it doesn't cause more work for the TIP maintainers, or for you, I
> > appreciate it.  But if it does cause more work, don't worry about it, I
> > can handle backporting things as needed.
> 
> Note that the role of x86/pti is not just to identify backporting commits for 
> -stable, but to allow us on the x86 tree side to see how current upstream work 
> interacts, and proactively allow us to group commits in a low-friction fashion.
> 
> So even if you didn't follow the x86/pti branch at all, -stable would _still_ 
> benefit from the tip:x86/pti approach and the inherent backportability of all the 
> PTI and Spectre commits.

Put differently: this approach isn't a zero-sum game of 'upstream conflicts versus 
-stable conflicts', where if we don't resolve a conflict upstream then -stable has 
to do it and vice versa.

The tip:x86/pti approach actively avoided literally _dozens_ of nasty conflicts in 
the -stable space, at an (IMHO) much lower cost to upstream. It also IMHO 
successfully avoided the destabilizing effect that otherwise the backporting of 
most of ~300 these commits would have caused on the widely deployed v4.14 and 
v4.15 base kernels ....

Had I done this latest pull request a bit smarter Linus would not have seen these 
two conflicts either, so I still think this is the right approach and the cost to 
upstream is very low.

The x86 tree maintenance overhead was obviously higher due to all this, but right 
now I'm reasonably happy about the backporting aspect/overhead, because the v4.14 
and v4.15 stable kernels are now essentially using and testing our latest upstream 
code, which allows it to stabilize a lot faster.

Thanks,

	Ingo