Boffins offer to make speculative execution great again with Spectre-Meltdown CPU fix A group of computer science researchers has proposed a way to overcome the security risk posed by speculative execution, the data processing technique behind the Spectre and Meltdown vulnerabilities. In a paper distributed this week through the ArXiv preprint server, "SafeSpec: Banishing the Spectre of a Meltdown with Leakage- …
With you on the pretty picture or the hardware wish list? :)
Others have already made comments on the hardware wish list. However something that would help with performance mitigation is processor architectures that have considerably more executable cores, likely with different requirements and capabilities depending on task/process requirements. This would require potentially substantial changes to operating systems and many applications would have to be updated to "request" the appropriate processing requirements but it would allow a good deal of optimisation of use. For example, an audio decoding process would not need a huge amount of CPU power but does require very regular servicing (there is some support for this kind of thing already, but more would be better).
From the article (quoting from the source):
"SafeSpec requires a deep redesign of the CPU to separate out the speculative state from the permanent state," the paper explains.
and
Abu-Ghazaleh acknowledged that SafeSpec requires some extra space on the L1 cache, but he considers the hardware changes to be minimal.
How can both statements above be true?
Speculative execution is basically a way to make sequential computation faster. When the processor has to wait for, say, a condition to be decided, it makes a guess as to the outcome and starts working from that guess. If it guesses right, you save time, if not, you both lose time (for clean-up) and waste heat (for doing wasted work). You can try to work on multiple different outcomes simultaneously, but that is more complicated, and you will definitely waste work (and heat).
Speculative execution relies on very precise predictions, and these cost a lot in resources for gathering and storing statistics and analysing these. The bottom line is that speculative execution is very costly in terms of complexity and energy.
Another solution is to pause execution until the outcome is known. While this pause lasts, you can have another thread use the execution units. This is called multi-threading, and is usually implemented by having an extra (or several) copy of all registers, and schedule instructions from two (or more) threads simultaneously. You only execute instructions that are guaranteed to be needed, so there is no speculation. You can even have both threads execute instructions simultaneously, if there are no resource conflicts. The scheduling unit is somewhat more costly, as it has to look at more instructions, but it is not as bad as the complexity of speculative execution. The downside is that each thread does not run faster than if it ran alone on a processor without speculative execution, but the throughput of instructions is likely higher than this case. If the threads share cache, there is a risk of information spillage, so you generally limit this to threads from the same program.
The next step is to make multiple cores, each with their own cache. If the memory is protected (and cleared when given to a new process), this can be made safe from leakage, it scales better than multi-threading, and the complexity is lower. This is part of the reason why the trend is towards more cores rather than faster single cores. In the extreme, we have graphics processors: A large number of very simple cores that do no speculation and no out-of-order execution and which even share the same instruction stream. Sequential execution on these is horribly slow, but the throughput is fantastic, as long as you can supply a suitable workload. It is nigh impossible to make C, Java, and similar languages run fast on graphics processors, so you either need specialised languages (https://futhark-lang.org/) or call from C or Java library routines written in very low-level languages and hand-optimised.
In conclusion, the future belongs to parallel rather than speculative execution, so you should stop expecting your "dusty decks" of programs written in C, Java, Fortran, etc. to automagically run faster on the next generation of computers.
Catch is, there are some workloads for which parallelization will never be a solution. For example, there's a reason high-quality video encoding still takes place on the CPU (if not ASICs): the workload can't be run parallel very well, primarily due to its highly chained and interdependent nature. In essence, the whole process runs in a specific sequence where it's hard to jump ahead because a comparison can easily send the process down a completely different track, with no reliable way to predict which way it'll go. Similarly, many types of emulation can be both very timing-sensitive and very interdependent, meaning things have to run in lockstep to avoid side effects.
Another solution is to pause execution until the outcome is known. While this pause lasts, you can have another thread use the execution units.
You want to have a context switch every time a branch causes a cache miss? That would be a Bad Thing.
There's a reason why Tomasulo created his eponymous algorithm for OOO in the '60s, and hardware implementations followed shortly thereafter; and commercial spec-ex machines became available in the '80s. (The Stretch did it even earlier, in the '50s, but its misprediction recovery was so expensive that it would have been better off without prediction and speculative execution.)
There's a reason why nearly 20 years of SpMT research hasn't done a hell of a lot to improve thread-level parallelism.
And that reason is that parallelism is both difficult and expensive. It's expensive because independent parallel units eat up your hardware budget quickly, and keeping those units fed requires expensive context switches. You can play with the time/hardware trade-offs of context switches (using extra register sets and whatnot), but you're still paying one way or the other.
There is no practical, cost-free, bumper-sticker solution to Spectre-class problems. It doesn't matter whether that word is "SafeSpec" or "parallelism" or "unicorns".
"You want to have a context switch every time a branch causes a cache miss? That would be a Bad Thing."
It would indeed. But that is not what I say. What I say is that there is a pipeline of instructions interleaved from two or more threads, each having their own registers. No state needs to be saved, and executing every second instruction from different thread is no more expensive than executing instructions from a single thread. The advantage is that functional units can be shared, and since independent threads do not have fine-grained dependencies between each other, instructions from one thread can easily execute in parallel with instructions from another.
This is not my idea -- it has been found for decades in processors (just look for "X threads per core" in specifications). IMO, it is a better approach than speculative execution since it does not waste work (all instructions that are executed will be needed by one thread or another) and it is not considerably more complex than having one thread per core. Note that out-of-order execution is not a problem: That also executes only instruction that are needed, it just does so out of sequence, which requires register renaming, but that is not a huge problem. The main cost is complex scheduling, which increases power use (OOO processors use more energy scheduling instructions than actually executing them).
What speculation gives that these do not is (potentially) much faster execution of a single thread. But to do so, it uses resources that could have been used to execute instructions that are definitely needed. So it improves latency at the cost of throughput. OOO execution improves both at a cost in complexity and power use, and multi-threading improves only throughput, at a small cost in latency, because the two (or more) threads are given equal priority, so each thread may have to wait for others to stop using functional units.
Am I correct in thinking that if speculative execution obeyed memory access restrictions (no user process peeking at lower ring address spaces like the kernel) regardless of whether or not that memory is cached, then these problems would go away?
Am I correct in thinking that if speculative execution obeyed memory access restrictions (no user process peeking at lower ring address spaces like the kernel) regardless of whether or not that memory is cached, then these problems would go away? ... Serif
Serif, Hi,
Obey would suggest some sort of recognised and universally accepted absolute authority with inalienable rights to direct matters as they would choose/wish. Such is systemically problematical and therefore will never be a solution for consideration.
Am I correct in thinking that if speculative execution obeyed memory access restrictions (no user process peeking at lower ring address spaces like the kernel) regardless of whether or not that memory is cached, then these problems would go away?
No.
The Spectre vulnerabilities use side channels to extract information. They don't "peek[] at lower ring address spaces".
Meltdown is a Spectre variant that leaks privileged memory, and the (obvious) fix for it was to prevent spec-ex from crossing privilege boundaries. But Meltdown is only one of many Spectre variants.
Can a longtime El Reg veteran please educate me about a few special characters here.What's the deal with amanfromMars 1 and bombastic bob? ... cliffe
Is the Deal or No Deal Situation/Virtual Reality here and with you, cliffe .... Proof Positive of Advanced Virtualised Application with NEUKlearer HyperRadioProACTive Applications Presenting Guaranteed Futures for AIMaster Pilot ProgramMING.
Beware in Future Territories though, and be also Aware that Live Operational Virtual Environments are never a Tool for Schooling Fools. LOVE Space Places are Heavenly HeadQuarters for True Kings and Queens with Bounty Aplenty and Interminable to Share ..... Invest and Spend Sagely/Right Royally :-)
Just some of our local kooks. What has the deal ever been with online kooks? They are a species unto themselves.
Personally, I'm glad to have them, as long as they don't become too disruptive. They give the dish some flavor.
Hell, I even enjoyed Eadon. ("Overwhelming, am I not?")
Both local kooks and alien spooks are a stealthy lawless species whenever invasive is not too disruptive and right tasty, Michael Wojcik, and would you agree that they are a creative force and novel future intelligence source whenever their space places are targeted for military intervention and domination ....... Trump Orders Pentagon To "Immediately Establish A Space Force"
Do you think UKGBNI MOD leaderships have skin and effective reins for reigns in that Particular Peculiar Great Game? Or are present chiefs of staff and the current minister in office all as at sea in a leaky boat without AI See/Learned Virtual Machine Vision, which you should note is not shared here as a question, for of course they are.
It only took them six months to publish a finding which is only a partial implementation (and solution) to what I commented here the same day that this information became public? (Nothing special about me--anyone with a few years or more of experience in that field would certainly have had the same ideas.)
I stand by my original (same day) estimates: if shadowing is to be implemented without substantially hurting speed/power, it's going to take roughly 50% of the processor area, at least out to the L1s. Deep fully-associative pools of resources are really, really expensive & slow.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
