With the ever-increasing number of performance-impacting security mitigations, I have to wonder if we'll eventually see cores specialize into secure and insecure variants. That's performance being left on the table after all, and there are use cases where data security either doesn't matter or can be achieved to an acceptable degree by airgapping. General purpose chips could have a mix, and just throw all of the sensitive tasks at the S cores.
From what I understand, the vulnerability allows access to protected memory. So having a secure core on the same CPU wouldn't help, if the malware runs on an insecure core.
So instead, you just don't want security critical stuff run on a shared system in the cloud.
Thank you for your submission! Unfortunately, your submission has been removed for the following reason:
* It is a duplicate post, or it contains the same information as a previous post. This also includes re-hosting news from the past as new information.
>This update mitigates the flaw with relatively low performance impact (up to 2.7% in lmbench tests).
Lol such a terrible article, probably just AI summary, looks like they quoted the mistype from the original article that was supposed to represent Alder Lake.
.
These are the actual figures from the research paper:
Mitigation overhead in UnixBench / lmbench.
CPU | PRED_DIS_S | Retpoline
---|---|----
Sapphire Rapids | 1.7% / 6.4% | 2.4% / 8.0%
Raptor Lake | 1.1% / 6.3% | 2.2% / 6.6%
Alder Lake | 1.5% / 4.7% | 2.4% / 8.2%
Rocket Lake | - | 3.1% / 8.3%
Comet Lake | - | 0.5% / 2.4%
Coffee Lake Refresh | - | 0.5% / 1.6%
The table shows the non-microcode mitigation overhead, tested by the researchers in the original paper, which is not the same thing.
2.7% was the highest measured overhead from the microcode update.
7 Comments
RuinousRubric@reddit
einmaldrin_alleshin@reddit
hardware-ModTeam@reddit
AreYouAWiiizard@reddit
TheRealBurritoJ@reddit
AreYouAWiiizard@reddit
ElementII5@reddit (OP)