[MODERATED] Re: [PATCH v2 3/8] MDSv2 5

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

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.  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.  That said, I expect the chance
is somewhere between rare and astronomical outside of a demo setup.

~Andrew