From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 01 Mar 2019 22:14:31 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gzqQH-0005GW-J9 for speck@linutronix.de; Fri, 01 Mar 2019 23:14:30 +0100 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 427922DB72A for ; Fri, 1 Mar 2019 22:14:23 +0000 (UTC) Received: from tonnant.bos.jonmasters.org (ovpn-124-62.rdu2.redhat.com [10.10.124.62]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9EE3219C72 for ; Fri, 1 Mar 2019 22:14:22 +0000 (UTC) References: <20190222222418.405369026@linutronix.de> <20190222224149.440041789@linutronix.de> <20190226141937.7bdg2gs5l4d6z3rf@treble> From: Jon Masters Message-ID: Date: Fri, 1 Mar 2019 17:14:21 -0500 MIME-Version: 1.0 In-Reply-To: Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="nnwtiKUQT3dRR2RxNGzNjsU0G6xQGnSLI"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --nnwtiKUQT3dRR2RxNGzNjsU0G6xQGnSLI Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Jon Masters To: speck for Jon Masters Subject: Re: [patch V4 04/11] x86/speculation/mds: Add mds_clear_cpu_buffer() --nnwtiKUQT3dRR2RxNGzNjsU0G6xQGnSLI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/1/19 3:58 PM, speck for Jon Masters wrote: > On 2/26/19 9:19 AM, speck for Josh Poimboeuf wrote: >=20 >> On Fri, Feb 22, 2019 at 11:24:22PM +0100, speck for Thomas Gleixner wr= ote: >>> +MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to= manage >>> +L1 miss situations and to hold data which is returned or sent in res= ponse >>> +to a memory or I/O operation. Fill buffers can forward data to a loa= d >>> +operation and also write data to the cache. When the fill buffer is >>> +deallocated it can retain the stale data of the preceding operations= which >>> +can then be forwarded to a faulting or assisting load operation, whi= ch can >>> +be exploited under certain conditions. Fill buffers are shared betwe= en >>> +Hyper-Threads so cross thread leakage is possible. >=20 > The fill buffers sit opposite the L1D$ and participate in coherency > directly. They supply data directly to the load store units. Here's the= > internal summary I wrote (feel free to use any of it that is useful): >=20 > "Intel processors utilize fill buffers to perform loads of data when a > miss occurs in the Level 1 data cache. The fill buffer allows the > processor to implement a non-blocking cache, continuing with other > operations while the necessary cache data =E2=80=9Cline=E2=80=9D is loa= ded from a higher > level cache or from memory. It also allows the result of the fill to be= > forwarded directly to the EU (Execution Unit) requiring the load, > without waiting for it to be written into the L1 Data Cache. >=20 > A load operation is not decoupled in the same way that a store is, but > it does involve an AGU (Address Generation Unit) operation. If the AGU > generates a fault (#PF, etc.) or an assist (A/D bits) then the classica= l > Intel design would block the load and later reissue it. In contemporary= > designs, it instead allows subsequent speculation operations to > temporarily see a forwarded data value from the fill buffer slot prior > to the load actually taking place. Thus it is possible to read data tha= t > was recently accessed by another thread, if the fill buffer entry is no= t > reused. >=20 > It is this attack that allows cross-thread SMT leakage and breaks HT > without recourse other than to disable it or to implement core > scheduling in the Linux kernel. >=20 > Variants of this include loads that cross cache or page boundaries due > to further optimizations in Intel=E2=80=99s implementation. For example= , Intel > incorporate logic to guess at address generation prior to determining > whether it crosses such a boundary (covered in US5335333A) and will > forward this to the TLB/load logic prior to resolving the full address.= > They will retry the load by re-issuing uops in the case of a cross > cacheline/page boundary but in that case will leak state as well." Btw, I've various reproducers here that I'm happy to share if useful with the right folks. Thomas and Linus should already have my IFU one for later testing of that, I've also e.g. an FBBF. Currently it just spews whatever it sees from the other threads, but in the next few days I'll have it cleaned up to send/receive specific messages - then can just wrap it with a bow so it can print yes/no vulnerable. Ping if you have a need for a repro (keybase/email) and I'll go through our process for sharing as appropriate. Jon. --=20 Computer Architect | Sent with my Fedora powered laptop --nnwtiKUQT3dRR2RxNGzNjsU0G6xQGnSLI--