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 ; 19 Nov 2019 18:39:49 -0000 Received: from esa4.hc3370-68.iphmx.com ([216.71.155.144]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iX8Pj-00018g-Hh for speck@linutronix.de; Tue, 19 Nov 2019 19:39:48 +0100 Subject: [MODERATED] Re: LVI References: <20191119174008.7dbymix2eo4mrv57@treble> <59d8550a-a217-7d30-9b44-e6a31cb4addf@citrix.com> <20191119182709.a3hu63nrnbffiped@treble> From: Andrew Cooper Message-ID: Date: Tue, 19 Nov 2019 18:39:34 +0000 MIME-Version: 1.0 In-Reply-To: <20191119182709.a3hu63nrnbffiped@treble> Content-Type: multipart/mixed; boundary="pDU39IMW5oFxEr1xm5PNElvBslsB4She8"; protected-headers="v1" To: speck@linutronix.de List-ID: --pDU39IMW5oFxEr1xm5PNElvBslsB4She8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 19/11/2019 18:27, speck for Josh Poimboeuf wrote: >>> To protect the kernel, we'd presumably need to look for places where >>> users can trigger a faulting/assisting load. For example, >>> copy_from_user(). >>> >>> copy_from_user() has an LFENCE between the access_ok() check and the >>> actual copy to protect against Spectre v1. What if we move that LFEN= CE >>> to *after* the copy? I think that would protect against both Spectre= v1 >>> and LVI. >>> >>> Thoughts? >> The lfence before protects from speculating into copy_from_user() with= 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 very easy for an attacker to control. ~Andrew --pDU39IMW5oFxEr1xm5PNElvBslsB4She8--