Google security researchers have come to the conclusion that speculative execution attacks are here to stay without drastic changes to modern CPU architectures, such as removing speculative execution entirely.
Spectre is here to stay: An analysis of side-channels and speculative execution
Related:
Patch for Intel Speculative Execution Vulnerability Could Reduce Performance by 5 to 35% [Update: 2]
Qualcomm Joins Others in Confirming its CPUs Suffer From Spectre, and Other Meltdown News
Congress Questions Chipmakers About Meltdown and Spectre
What Impact Has Meltdown/Spectre Had on YOUR Systems?
Intel Admits a Load of its CPUs Have Spectre V2 Flaw That Can't be Fixed
Intel FPU Speculation Vulnerability Confirmed
New Spectre Variant SpectreRSB Targets Return Stack Buffer
Intel Discloses a Speculative Execution Attack in Software Guard eXtensions (SGX)
Intel 'Gags' Linux Distros From Revealing Performance Hit From Spectre Patches
MIT Researchers Claim to Have a Solution for Some Speculative Execution Attacks
Spectre, Meltdown Researchers Unveil 7 More Speculative Execution Attacks
New Side-Channel Leak: Researchers Attack Operating System Page Caches
(Score: 0) by Anonymous Coward on Sunday February 17 2019, @01:35PM
"Perhaps it is difficult..."
A system call is a coordinated dance between the cpu and os.
The goal is to make it quick to move between the user and kernel space, but only thru carefully defined call gates.
The dance takes many clocks and so is in many stages of the pipeline at once.
Unless the S/W is able to greatly reduce the rate of system calls, speed requires that this involve speculation.
Speculation means that memory cycles get started before a memory protection check.
This means not verifying that if the address accesses protected memory, then the machine state and code that requests the cycle must be on the right side of the call gate.
This is necessary because these things may not be available early enough in the pipeline to prevent the memory cycle start.
This was thought to be ok because eventually the fruits from the cycle result would be ignored.
These bugs demonstrate that they are not completely ignored because they can effect the cache state.
This seems to me like the 3 bears.
Checking before the cycle start is too early and very slow.
Checking the state as we do is too late, but very fast.
Checking after the cycle, but before using the result may be just right.
In other word, make it ok to start the kernel memory read in user state, but tag the fruits of the cycle as to who and where they came from so that later stages in the pipeline can be more aware of what is happening.
Later stages needs to include the cache update, but the difficult part is what else?