From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from userp2130.oracle.com ([156.151.31.86]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f8d99-0001om-IJ for speck@linutronix.de; Wed, 18 Apr 2018 04:48:36 +0200 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3I2keU9013566 for ; Wed, 18 Apr 2018 02:48:28 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2hdrxnrk5d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Apr 2018 02:48:28 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3I2mR5V024875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 18 Apr 2018 02:48:27 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3I2mRVh029019 for ; Wed, 18 Apr 2018 02:48:27 GMT Date: Tue, 17 Apr 2018 22:48:22 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: GPZv4 Message-ID: <20180418024816.GA6450@localhost.localdomain> 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> MIME-Version: 1.0 In-Reply-To: <67ef414c-f57c-0300-973b-f8898ee4d3b1@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Apr 17, 2018 at 06:02:47PM -0400, speck for Jon Masters wrote: > On 04/17/2018 06:01 PM, speck for Thomas Gleixner wrote: > > On Tue, 17 Apr 2018, speck for Jiri Kosina wrote: > > > >> On Tue, 17 Apr 2018, speck for Jon Masters wrote: > >> > >>> The proposal would be that it only allows you to go one-way. You can say > >>> "I am vulnerable", turn off MD, but you can't say "I am not vulnerable". > >> > >> That means we probably never reach full coverage; the problem with this > >> "opt-in" aproach is that noone would ever bother (even more so as time > >> passess) to add this explicit "I am vulnerable" call into the source; it's > >> basically out of control, and thus unmaintainable. > > > > We had the same discussion with the per process kpti control ... > > Ok. Big hammer it is. 1) Are you thinking of a mix of a) big hammer (at boot up always disable memory disambiguation, aka mdd=auto or sbb=auto or sbbd=auto), along with b) inverting the prctl to opt-out - that is applications that feel they are safe can opt-out and do an prctl saying: memory disambiguation security issues be dammed - I want memory disambiguation on to get that 5% performance back. Obviously they would need to be new to know about this bit. And then any old application would suffer the performance penalty but would be secure. ? 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'. 3). Semantics of SBBD or MDD boot time knob. I followed the way spectre_v2 did it. That is this is knob is to disable something and they are: 'auto' - follow what the platform recommends. This being linux upstream discussion means following: on AMD - enable memory disambiguation. on Intel - no clue. For testing purposes I've left it as disable memory disambiguation. 'off' - ignore what the vendor/distro recommends. 'force' - disable it, even if the platform says enable it (like on AMD). And then two more to figure out when to apply the security glue: 'boot' or 'userspace'. This ties in to 1) - that is if we are not going to provide a 'userspace' option then there is no need to even provide the 'boot' option so then this sub-discussion becomes moot. Thomas (and Linus if you are skulking in the background) - you are the top-dog(s) here, can you give the guidance please so I can redo the patches on Thursday/Friday? P.S. I know the AMD secret sauce bits and can do the patches for this, but are other folks authorized for this?