Initial Performance Benchmarks of Linux's x86 Security Changes

Really glad to see some more useful benchmarks here from Phoronix!<p>Anyone who has done a lot of storage, or NFS, etc.. knows that the du usecase is pathological and likely the worst case.<p>Staying tuned for additional updates, for example he could use the boot flags to disable&#x2F;enable the support for this in order to eliminate other changes within the kernel.

Is it possible to sue Intel if you need ~30% more web servers because Intel built faulty processors? The argument would be that you had bought AMD if you had known about the flaw.

Historical context:<p>&quot;The mysterious case of the Linux Page Table Isolation patches&quot;<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16046636" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16046636</a>

With what is known about this bug so far, wouldn&#x27;t it be possible to mitigate it by locking the kernel to one CPU core, and run user processes on the other cores?<p>Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other? If that is true, then it seems that just isolating the kernel wouldn&#x27;t be enough.

It is interesting to see how posts and comments are written in a way that so far hides or downplays the severity and owner of this flaw.

So, as I understand it, the only way to avoid the rather huge performance hit is to use the pti=off switch, in effect opting out of KASLR on any Intel CPU newer than Pentium. Is this correct?

These cache vulnerabilities can probably be mitigated with lower performance penalties on CPUs with Intel CAT. It&#x27;s only available on Intel&#x27;s Xeon SKUs though.