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 1fA0hl-00052z-9s for speck@linutronix.de; Sun, 22 Apr 2018 00:10:02 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E92AF406E8A4 for ; Sat, 21 Apr 2018 22:09:53 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-120-78.rdu2.redhat.com [10.10.120.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5CCC62166BAD for ; Sat, 21 Apr 2018 22:09:53 +0000 (UTC) Subject: [MODERATED] Re: [patch 07/11] [PATCH v2 07/10] Linux Patch #7 References: <20180420022613.270943302@localhost.localdomain> <20180420174242.GO13977@pd.tnic> <20180421032701.GA4490@localhost.localdomain> <20180421090345.GA18575@pd.tnic> <20180421122117.GA5337@localhost.localdomain> <20180421192509.GD18575@pd.tnic> From: Jon Masters Message-ID: <077b5de0-b384-5daa-1b10-be6ca2e5c6ab@redhat.com> Date: Sat, 21 Apr 2018 18:09:51 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="zK5PWlAStrL5SOdr51qp0iaMMz4aGajPp"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --zK5PWlAStrL5SOdr51qp0iaMMz4aGajPp Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/21/2018 05:41 PM, speck for Linus Torvalds wrote: > On Sat, 21 Apr 2018, speck for Borislav Petkov wrote: >> >> I prefer X86_FEATURE_MDD and X86_FEATURE_USE_MDD which is >> straight-forward and in line with the other mitigations. And we query >> the USE_MDD flag only. The MDD one will be for /proc/cpuinfo and USE_M= DD >> used by the code. >=20 > At the risk of bike shedding, can we *please* just write out "Store buf= fer=20 > bypass" and "Memory disambiguation" instead of using SBB amd MD? Very reasonable. > The patches aren't so big, and these names won't be used so much that w= e=20 > can't use longer names. Yes, yes, we use PTI for the page table isolati= on,=20 > but that had a much wider impact. For Spectre v1 we at least use _half_= =20 > words like "nospec". >=20 > Maybe even X86_FEATURE_STBUF_BYPASS? >=20 > And X86_FEATURE_STBUF_BYPASS_MITIGATE? > And the same goes for the kernel command line. Saying "ssb=3Dauto" is n= ot=20 > helpful to *anybody*. Can you make a call on the above now? We're happy to go along with whatever but need to get the other arches aligned behind whatever we're doing (IBM p, z, and Arm are working on patches as well as others), and then crank on the distro patches based upon whatever is agreed here. So might I ask your opinion of the following list of terms/uses? (we've been previously asked by Thomas to retain the inverted logic - so you enable a mitigation which disables a CPU performance optimization) * spec_store_bypass_disable=3Dauto/off/on * /sys/devices/system/cpu/vulnerabilities/speculative_store_bypass * X86_FEATURE_SPEC_STORE_BYPASS_DISABLE * X86_FEATURE_USE_SPEC_STORE_BYPASS_DISABLE > Nobody is going to get carpal tunnel syndrome from typing that too ofte= n.=20 > I guarantee it. :) Jon. P.S. I didn't say "stbuf" in the above because it's not required that a uarch implement only speculation on the store buffer. It could be that a uarch uses an integrated load/store queue (LSQ) and searches that, or it could be that stores are tracked in another manner (e.g. IBM). All the exploit relies upon is close-to-retirement store conflict handling. And we have several variants of this exploit coming up that rely upon slight twists of store-to-load forwarding. I expect those will come up here. --=20 Computer Architect | Sent from my Fedora powered laptop --zK5PWlAStrL5SOdr51qp0iaMMz4aGajPp--