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 ; 11 Dec 2018 00:09:48 -0000 Received: from smtp.ctxuk.citrix.com ([185.25.65.24] helo=SMTP.EU.CITRIX.COM) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gWVcQ-0008Ce-OW for speck@linutronix.de; Tue, 11 Dec 2018 01:09:47 +0100 Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> From: Andrew Cooper Message-ID: Date: Tue, 11 Dec 2018 00:09:25 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="WYYkA7yOLB4FDTNeA0dMhnFH73B7udz0X"; protected-headers="v1" To: speck@linutronix.de List-ID: --WYYkA7yOLB4FDTNeA0dMhnFH73B7udz0X Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 10/12/2018 23:00, speck for Linus Torvalds wrote: > The data that system calls touch is basically already user data. Sure, > there may be kernel pointers etc there, but we've already accepted > those leaking locally for all the usual reasons that we have no > control over. > > So the whole "let's add crazy long sequences to every kernel exit" is > not going to happen. Not without a lot more explanations. The load buffers and fill buffers are very unlikely to have interesting data in by the time you return to userspace, because of normal things we do on the exit path. It is the store buffers which are the problem case. At some future point, e.g. when a userspace store takes an assist (setting A/D bits is the example given, but there are other cases which manifest this behaviour), a subsequent load-to-store-forward can leak the stale contents of store buffer entry. The store buffers are as wide as the vector pipeline, so while the lower 64 bits are almost certainly clobbered, the upper bits will be from the last vector operation which was allocated to this store buffer.=C2=A0 As XSAVE doesn't use all the store buffer entries, and doesn't make uniformly-wide writes, the upper bits of the store buffer could be from several context switches ago. In the case of using SIMD-accelerated crypto, you've got a chance of being able to find plaintext in the upper bits of the store buffer. I can't speak to how easy this is to exploit in practice (I've not tried yet), or what else perturbs the store buffers (apparently on some CPUs, rep operations with a sufficient %ecx will use the entire width of the store buffer), but there is a plausible risk that you really can get interesting data from the store buffers.=C2=A0 That said, I expect the ch= ance is somewhere between rare and astronomical outside of a demo setup. ~Andrew --WYYkA7yOLB4FDTNeA0dMhnFH73B7udz0X--