From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 20 Nov 2019 14:11:57 -0000 Received: from esa6.hc3370-68.iphmx.com ([216.71.155.175]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iXQi2-0000B5-SV for speck@linutronix.de; Wed, 20 Nov 2019 15:11:56 +0100 Subject: [MODERATED] Re: LVI References: <20191119174008.7dbymix2eo4mrv57@treble> <59d8550a-a217-7d30-9b44-e6a31cb4addf@citrix.com> <20191119182709.a3hu63nrnbffiped@treble> <20191119210007.zrweuamvb44x7evv@treble> <20191119210318.2itaoogwxu2oezok@treble> From: Andrew Cooper Message-ID: Date: Wed, 20 Nov 2019 14:11:41 +0000 MIME-Version: 1.0 In-Reply-To: <20191119210318.2itaoogwxu2oezok@treble> Content-Type: multipart/mixed; boundary="DUmucATk6xfVRPN0hokSGA9ikUalccEjB"; protected-headers="v1" To: speck@linutronix.de List-ID: --DUmucATk6xfVRPN0hokSGA9ikUalccEjB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 19/11/2019 21:03, speck for Josh Poimboeuf wrote: > On Tue, Nov 19, 2019 at 03:00:07PM -0600, speck for Josh Poimboeuf wrot= e: >> On Tue, Nov 19, 2019 at 06:39:34PM +0000, speck for Andrew Cooper wrot= e: >>> On 19/11/2019 18:27, speck for Josh Poimboeuf wrote: >>>>>> To protect the kernel, we'd presumably need to look for places whe= re >>>>>> users can trigger a faulting/assisting load. For example, >>>>>> copy_from_user(). >>>>>> >>>>>> copy_from_user() has an LFENCE between the access_ok() check and t= he >>>>>> actual copy to protect against Spectre v1. What if we move that L= FENCE >>>>>> to *after* the copy? I think that would protect against both Spec= tre v1 >>>>>> and LVI. >>>>>> >>>>>> Thoughts? >>>>> The lfence before protects from speculating into copy_from_user() w= ith a >>>>> bad pointer.=C2=A0 This protection is still necessary. >>>> What's the harm of speculating the copy with a bad pointer if we can= >>>> confirm there are no gadgets between the copy and the LFENCE? >>> Because the other hyperthread can read the data directly out of the >>> cache using L1TF/MDS/other as applicable. >>> >>> True - this is applicable to any speculative OoB read on the first >>> thread so isn't unique to copy_from_user(), but copy_from_user() is v= ery >>> easy for an attacker to control. >> Ok, I guess had just assumed we didn't care about SMT at this point, w= e >> should at least try to do a best effort there. >> >> Does this match your thinking? >> >> if (SMT && (BUG_L1TF || BUG_MDS || BUG_TAA)) >> lfence(); >> =09 >> ... do the copy ... >> >> if (BUG_LVI) >> lfence(); > Or, taking SMAP and Spectre v1 into account... > > if (!SMAP && SMT && (BUG_L1TF || BUG_MDS || BUG_TAA)) > lfence(); > =09 > ... do the copy ... > =20 > if (!SMAP && (BUG_SPECTRE_V1 || BUG_LVI)) > lfence(); I'd be hesitant to depend on SMAP like this, until we get some concrete statements on the behaviour we may rely upon from both Intel and AMD. Their implementations are not necessarily equivalent when it comes to hidden side effects on speculation. ~Andrew --DUmucATk6xfVRPN0hokSGA9ikUalccEjB--