Wait, Intel thought the insecure optimization which lead to this vulnerability was such a great idea that they actually patented it? Wow.
The thing to understand about the quoted portion (here is the patent: https://patents.google.com/patent/US7603527B2/en?oq=7%2c603%...), 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.
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.
0: ie, there exists a entity (other than the end user) that should not have access.
"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
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  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."
WTF starts to be rather overloaded acronym. Reminds me for example of "Wobbly Transformation Format" ...
(I would also prefer descriptive names rather than this kind of marketing, but these are the times we live in.)
tldr: Intel. Intel is impacted. Again.
Hardware designers need to come up with better isolation mechanisms.