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 20:59:05 -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 1gzpFH-0004Ci-7P for speck@linutronix.de; Fri, 01 Mar 2019 21:59:03 +0100 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6D3FF653CB for ; Fri, 1 Mar 2019 20:58:55 +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 0864960DB4 for ; Fri, 1 Mar 2019 20:58:54 +0000 (UTC) References: <20190222222418.405369026@linutronix.de> <20190222224149.440041789@linutronix.de> <20190226141937.7bdg2gs5l4d6z3rf@treble> From: Jon Masters Message-ID: Date: Fri, 1 Mar 2019 15:58:53 -0500 MIME-Version: 1.0 In-Reply-To: <20190226141937.7bdg2gs5l4d6z3rf@treble> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="69h5cb9IA21Vx0XbEGA1xEP9Ywoaach0q"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --69h5cb9IA21Vx0XbEGA1xEP9Ywoaach0q Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Jon Masters To: speck for Josh Poimboeuf Subject: Re: [patch V4 04/11] x86/speculation/mds: Add mds_clear_cpu_buffer() --69h5cb9IA21Vx0XbEGA1xEP9Ywoaach0q Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/26/19 9:19 AM, speck for Josh Poimboeuf wrote: > On Fri, Feb 22, 2019 at 11:24:22PM +0100, speck for Thomas Gleixner wro= te: >> +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 resp= onse >> +to a memory or I/O operation. Fill buffers can forward data to a load= >> +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, whic= h can >> +be exploited under certain conditions. Fill buffers are shared betwee= n >> +Hyper-Threads so cross thread leakage is possible. 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): "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 loade= d 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. 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 classical 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 that was recently accessed by another thread, if the fill buffer entry is not reused. 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. 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." Jon. --=20 Computer Architect | Sent with my Fedora powered laptop --69h5cb9IA21Vx0XbEGA1xEP9Ywoaach0q--