From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fAfna-0006jN-80 for speck@linutronix.de; Mon, 23 Apr 2018 20:02:46 +0200 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 172DD8DC48 for ; Mon, 23 Apr 2018 18:02:40 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-124-56.rdu2.redhat.com [10.10.124.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D94DD15562 for ; Mon, 23 Apr 2018 18:02:39 +0000 (UTC) Subject: [MODERATED] Re: [patch 07/11] [PATCH v2 07/10] Linux Patch #7 References: <20180421223538.GF18575@pd.tnic> <45c96d89-f75b-9770-6032-ca87115a0e0a@redhat.com> <0de04dd1-0f35-dc0e-d27a-dec03ed0f138@redhat.com> <20180422093545.GA32218@pd.tnic> <2c7fa188-cd84-1a10-56cb-358d3f859559@redhat.com> <20180422103456.GC32218@pd.tnic> <3d7880e7-6b67-b35a-a090-2854f7db54ff@redhat.com> <2184fc1b-dcbc-a40c-64da-4965c7c48faa@redhat.com> <20180423175151.GA21779@dhcp-10-159-147-220.vpn.oracle.com> <338dd556-fe22-d17b-050b-0cc116363f67@redhat.com> From: Jon Masters Message-ID: Date: Mon, 23 Apr 2018 14:02:39 -0400 MIME-Version: 1.0 In-Reply-To: <338dd556-fe22-d17b-050b-0cc116363f67@redhat.com> Content-Type: multipart/mixed; boundary="ybf7KPaLEtqQVt7kxzMmFbKtWblxrbMIr"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --ybf7KPaLEtqQVt7kxzMmFbKtWblxrbMIr Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/23/2018 02:01 PM, speck for Jon Masters wrote: > On 04/23/2018 01:51 PM, speck for Konrad Rzeszutek Wilk wrote: >>> >>> Additional: I spoke with Intel a few minutes ago to impress upon them= >>> that we'll (RH) have to leave MD disabled by default unless they driv= e >>> the prctrl/other solutions for vulnerable processes they'd like to se= e. >> >> I believe (and Linus, please correct me here) that the question of >> toggling on/off SPEC_CTRL MSR on user-space entrance is a no-go. >=20 > To clarify, it's not a userspace toggling of an MSR. It would be a prct= l > (e.g. a new "SPECULATION_VULNERABILITY" major with some minor variants)= > that would allow processes to say "I'm vulnerable to X" or somesuch. >=20 > On x86, that might then allow us to have the mechanics of globally > enabling MDD, disabling it on entry to the kernel (due to stack attack,= ^^^ MD not MDD here (two all nighters in a row) > to be debated), and selectively disabling it for known vulnerable > processes. Yea, it's a lot more complicated. >=20 > Anyway, I'm personally ok with a global knob. It's just that we're > getting a lot of pressure from Intel and AMD to not do that. I've asked= > Intel to talk with Thomas and Linus and represent their opinions here > because I don't want it to seem like this is my asking for knobs! ;) >=20 > Jon. >=20 --=20 Computer Architect | Sent from my Fedora powered laptop --ybf7KPaLEtqQVt7kxzMmFbKtWblxrbMIr--