
Fallout: Reading Kernel Writes from User Space - lainon
https://arxiv.org/abs/1905.12701
======
makomk
'Remarkably, the patent explicitly states that: "if there is a hit at
operation 302 [partial match using page offsets] and the physical address of
the load or the store operations is not valid, the physical address check at
operation 310 [full physical address match] may be considered as a hit"'

Wait, Intel thought the insecure optimization which lead to this vulnerability
was such a great idea that they _actually patented it_? Wow.

~~~
rayiner
The load and store buffers are an incredibly performance sensitive part of the
processor. To be maximally conservative you'd fully resolve the physical
address of the load and store (including the access check) before allowing the
load to bypass a non-aliasing store, or before forwarding store data to a
load. But you could be waiting awhile (for example, many processors have
multiple levels of TLBs), during which time you've held up a load for no good
reason.

The thing to understand about the quoted portion (here is the patent:
[https://patents.google.com/patent/US7603527B2/en?oq=7%2c603%...](https://patents.google.com/patent/US7603527B2/en?oq=7%2c603%2c527)),
is that you don't know if "the physical address of the load or the store
operations is not valid" until long before you get to operation 302. The
quoted paragraph is about how you get the correct result even if you
optimistically forward the store data to the load.

The gist of the optimization is as follows. Operation 302 checks if the page
offset of a load matches a store. Address translation won't effect the page
offset (just the page number). So if there is a match, there is a good chance
that the operations alias. Now, say you do a store followed by a load. At 302,
you may not have the actual physical address of the load and/or store. But if
there is a match at 302 (in the page offset), there is a good chance you're
just loading from a location you recently stored to. Optimistically forwarding
the data from the store buffer to the load allows the load to continue to make
progress. Otherwise, you'd have to wait for both physical addresses to be
resolved at Operation 310 before the load could continue.

As an aside, I think de-tuning this at the microcode or architectural level is
probably a fool's errand. What you need is an architectural mode that
basically says "this code needs to be protected from information leakage due
to timing attacks." Then you can turn off speculation or whatever in such
code.

~~~
bdonlan
Having a mode switch isn't enough; potentially any part of the program could
contain a spectre gadget, so you'd need to run the whole program in that mode.

A perhaps better approach would be to ensure that speculation aborts actually
do clean up the entire microarchitectural state - ensuring that the cache
state (and other persistent state) isn't affected by aborted predicted
execution.

~~~
a1369209993
Specifically, the question is whether the current process (user or kernel) has
mapped _anywhere in its address space_ data the attacker[0] should not be able
to access.

0: ie, there exists a entity (other than the end user) that should not have
access.

------
reubenmorais
Does anyone know of a list/summary of all the different ways OoO can be
exploited to create vulnerabilities? It seems there's a new attack coming out
every month, it'd be nice to see a list of attacks, affected configurations,
and workarounds if they exist.

~~~
debatem1
I like this one:
[https://arxiv.org/pdf/1811.05441](https://arxiv.org/pdf/1811.05441)

------
molyss
for those who want to know about who's impacted :

"Intel. We notified Intel about our findings, including a preliminary writeup
and proof-of-concept code, on January 31st, 2019. Intel had acknowledged the
issue and requested an embargo on the results in this paper, ending May 14th,
2019. Intel has further classified this issue as Microarchitectural Store
Buffer Data Sampling (MSBDS), assigning it CVE-2018-12126 and a CVSS ranking
of Medium. Finally, Intel had indicated that we are the first academic group
to report this issue and that a similar issue was found internally as well.

AMD. We also notified AMD’s security response team regarding our findings,
including our writeup. AMD had investigated this issue of their architectures
and indicated that AMD CPUs are not vulnerable to the attacks described in
this paper.

ARM. We have also notified ARM’s security response team regarding our
findings. ARM had investigated this issue and found that ARM CPUs are not
vulnerable to the attacks described in this paper. IBM. Finally, we also
notified IBM security about the finding reported in this work. IBM had
responded that none of their CPUs is affected, including System-V and
PowerPC."

And here's a description (from the paper) of the mechanisms :

"The Mechanism Behind Fallout. Fallout exploits an optimization that we call
Write Transient Forwarding (WTF), which incorrectly passes values from memory
writes to subsequent memory reads. In a nutshell, when the program writes a
value to memory, the processor needs to first translate the virtual address of
the destination to a physical address and then acquire exclusive access to the
location. Rather than stalling the store instruction and subsequent
computation, the processor records the value and the address in the store
buffer, and continues executing the program. The store buffer then resolves
the address, acquires the access to the memory location and stores the data.

When a value is in the store buffer, care should be taken that subsequent
loads from the same address do not read stale values from memory. To solve
this, the processor matches the addresses of all load instructions against
addresses in the store buffer. In the case of a match, the processor forwards
the matching value from the store buffer to the load instruction. To increase
efficiency, the processor uses partial address matches to rule out the need
for store-to-load forwarding. WTF kicks in when a load instruction partially
matches a preceding store and the processor determines that the load is bound
to fail. In such cases, instead of cleaning up the state of the processor, it
marks the load as faulty, and incorrectly forwards the value of the partially
matched store.

Exploiting the WTF optimization. Fallout exploits this behavior to leak,
through a microarchitectural channel, the value that WTF incorrectly forwards.
The attacker deliberately performs a faulty load, causing the CPU to
transiently forward an incorrect value from the store buffer. We subsequently
leak the value using a Flush+Reload [58] side channel. As the store buffer is
a shared resource used by all software running on a CPU core, the incorrectly-
forwarded value might not even belong to the attacker’s process."

~~~
vardump
> ... we call Write Transient Forwarding (WTF)...

WTF starts to be rather overloaded acronym. Reminds me for example of "Wobbly
Transformation Format" [0]...

[0]:
[https://en.wikipedia.org/wiki/UTF-8#WTF-8](https://en.wikipedia.org/wiki/UTF-8#WTF-8)

~~~
Lorkki
"Fallout" also seems like a particularly bad choice of name to sell this
vulnerability by, since the game series is so well known.

(I would also prefer descriptive names rather than this kind of marketing, but
these are the times we live in.)

~~~
kazinator
The instantly recognizable connotation of "fallout" is "nuclear fallout". The
game series, which is post-apocalyptically themed, almost certainly derives
its name from that.

~~~
Lorkki
Of course it does. But in the context of computing equipment, the computer
game series was the first thing that came to my mind. Nuclear fallout is in a
different domain.

------
musicale
Shared resources, especially across privilege boundaries, almost always create
undesirable side channels that leak information.

Hardware designers need to come up with better isolation mechanisms.

