From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from static-242-42-24-46.ipcom.comunitel.net ([46.24.42.242] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f8nhH-0002LT-PC for speck@linutronix.de; Wed, 18 Apr 2018 16:04:31 +0200 Date: Wed, 18 Apr 2018 16:04:23 +0200 (CEST) From: Thomas Gleixner Subject: Re: GPZv4 In-Reply-To: <071ce2ea-c47d-9ae7-3e66-2e14ee32b97a@redhat.com> Message-ID: References: <20180417193105.GD3890@pd.tnic> <476c3e0b-dde6-6e6b-2054-6e71fa2c396b@redhat.com> <20180417203717.GF3890@pd.tnic> <47b619bf-8d07-c465-9017-583cf5ac80ee@redhat.com> <67ef414c-f57c-0300-973b-f8898ee4d3b1@redhat.com> <20180418024816.GA6450@localhost.localdomain> <071ce2ea-c47d-9ae7-3e66-2e14ee32b97a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: speck@linutronix.de List-ID: On Wed, 18 Apr 2018, speck for Jon Masters wrote: > On 04/18/2018 04:54 AM, speck for Thomas Gleixner wrote: > > On Tue, 17 Apr 2018, speck for Konrad Rzeszutek Wilk wrote: > >> 2). SBB vs MDD vs SBBD. > >> > >> MDD = Memory Disambiguation Disable > >> SBB = Speculative Store Bypass > >> SBBD = Speculative Store Bypass Disable > >> > >> Thomas likes 'MDD', Jon likes 'SBB', but he is also fine with 'SBBD'. > > > > I'm fine with SBBD as well. It's the same semantics as the other knobs as > > it controls the mitigation. > > Great. Might I recommend keeping what I sent to Konrad (both mdd and > ssbd recognized), but do whichever you like Konrad ;) > > > So can we for now just start with the minimal set of auto, off, on and then > > hash out the prctl or not question. The big hammer is the most important > > piece we need to have ready for merging when the embargo is lifted. > > I've sent the big hammer patches last night. Konrad's original set with > a few fixes, and just does "auto", "off", "on", and tested working ok. Can we please have proper mail submitted patches? These tarballs are a PITA. > >> P.S. > >> I know the AMD secret sauce bits and can do the patches for this, but > >> are other folks authorized for this? > > > > Groan. I do not know whether I am or not. > > > > This needs to stop. At some point we need to queue and stage the damned > > patches for both Intel and AMD. So AMD should get their act together and > > clarify the situation. Borislav can you please reach out to AMD? > > The problem is the performance hit. Both Intel and AMD take a hit, but > AMD have a few mitigating circumstances that causes them to be more > alarmed by disabling MD by default on their silicon. Chiefly, it's that > AMD won't speculatively bypass a load against the same base pointer, so > they're not vulnerable to the stack attack or some of the worst of it. > They will want the prctl type solution with userspace fixes deployed. Again. This is not the I want a pony session. I think I made it entirely clear how the procedure is: 1) Have working mitigation in place in the most simple way. That means the big on/off switch which comes with a big performance hit 2) Discuss the acceptance and the semantics of a prctl 3) If we agreed on #2, implement it and if #2 is dismissed then go out and have a drink. It's really that simple and I'm tired of this managerial education attidute which is coming in on every other mail. That's not helping at all and we all know by now that there is a performance hit and interested parties want to have a prctl of some sort to mitigate the performance hit. So instead of repeating this like a mantra, can we please get a proper description of the prctl semantics including a analysis of the security implications and the potential downsides vs. bitrot and maintainability. Thanks, tglx