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 1f8Wit-0005sQ-N0 for speck@linutronix.de; Tue, 17 Apr 2018 21:57:04 +0200 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9462F81A88C3 for ; Tue, 17 Apr 2018 19:56:56 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-125-161.rdu2.redhat.com [10.10.125.161]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 503BE2026DFD for ; Tue, 17 Apr 2018 19:56:55 +0000 (UTC) Subject: [MODERATED] Re: GPZv4 References: <20180417193105.GD3890@pd.tnic> From: Jon Masters Message-ID: <476c3e0b-dde6-6e6b-2054-6e71fa2c396b@redhat.com> Date: Tue, 17 Apr 2018 15:56:55 -0400 MIME-Version: 1.0 In-Reply-To: <20180417193105.GD3890@pd.tnic> Content-Type: multipart/mixed; boundary="xhBPQ1joPF5fCIdfJXh39ApOrtmcKbEMH"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --xhBPQ1joPF5fCIdfJXh39ApOrtmcKbEMH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 03:31 PM, speck for Borislav Petkov wrote: > On Tue, Apr 17, 2018 at 02:26:58PM -0400, speck for Jon Masters wrote: >> * AMD - They have chicken bits that can disable SSB. They won't provid= e >> these except on the condition that we agree not to disable by default.= >> Therefore, I have the magic bit info but can't share it quite yet. It >=20 > Oh, we know the bits. >=20 >> involves writing into two uarch specific MSRs and won't be SPEC_CTRL. = I >> can assist coordinating whatever is agreed here getting back to AMD. >=20 > There's nothing to coordinate - the default setting should be off on > AMD, that's it. Let's make sure we're talking about the right thing when we talk about things being on or off. I usually always talk about a performance feature being on or off, not a mitigation. Therefore, I read the above as "MD is off by default", meaning the performance feature is disabled. This is our current thinking. However, AMD disagree with this and prefer to leave the feature enabled by default. That would mean having to (at a minimum) address all of the userspace exposure with prctl(), seccomp(), or other interfaces, and get that all done within the next month. For the actual browsers, sure, there will be process isolation updates. So can you clarify what you meant by "off on AMD" by default? Jon. --=20 Computer Architect | Sent from my Fedora powered laptop --xhBPQ1joPF5fCIdfJXh39ApOrtmcKbEMH--