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]
Message-ID: <20180215081646.px477klttsj6axgp@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ