Intel Says Chip-Security Fixes Leave PCs No More Than 10% Slower (axios.com)

Intel trying to defuse concern that fixes to widespread chip security vulnerabilities will slow computers, released test results late Wednesday showing that personal computers won't be affected much and promised more information on servers. From a report: The chipmaker published a table of data showing that older processors handled typical tasks 10 percent slower at most, after being updated with security patches. The information covered three generations of processors, going back to 2015, running Microsoft's Windows 10 and Windows 7 computer operating systems. Further reporting: Intel, Microsoft offer differing views on impact of chip flaw

Comments

Note they only go back to 6th generation

[Hal_Porter]

I.e. the 6700K.

I.e. all the chips have PCID

It's a bit hazy when PCID and INVPCID became supported.

This says PCID was first supported in Westmere

https://www.realworldtech.com/...

Another long overdue improvement to the page tables is the Processor Context ID (PCID). The PCID is a field in each TLB entry that associates a given page to a process. Previously, Intel's TLB could only contain entries from a single process and whenever the CR3 register was written (e.g. a context switch), the TLB was flushed. The PCID lets pages from different processes safely inhabit the TLB together, so that CR3 writes no longer flush the TLB. Whenever a process tries to access a page in memory, the PCID is checked to determine whether the page is actually mapped into the process' address space; if the PCID does not match then a TLB miss occurred. This is very much analogous to Intel's VPID, which enables the TLB to contain pages from different virtual machines and avoid TLB flushes during VM transitions.

The LWN patch says

http://lkml.iu.edu/hypermail/l...

PCIDs are generally available on Sandybridge and newer CPUs. However,
the accompanying INVPCID instruction did not become available until
Haswell (the ones with "v4", or called fourth-generation Core). This
instruction allows non-current-PCID TLB entries to be flushed without
switching CR3 and global pages to be flushed without a double
MOV-to-CR4.

I.e. it'd be interesting to see what happens on a CPU old enough not to support enough of PCID/INVPCID to optimized KPTI.

The claims of >10% hits are all for these old CPUs.

huh?

[jbmartin6]

Is 10 percent "at most" supposed to be reassuring?

Fix to the Problem or Software Workaround?

[Anonymous Coward]

I'm still not clear on if the slowdown is due to the per-OS workaround, or if Intel is talking about their eventual fix to the hardware/firmware problem causing the slowdown...TFA seems to indicate a "fix" to Windows OS' specifically, which would imply the per-OS workaround.

Anyone?

Re:So AMD processors were faster all along?

[Anonymous Coward]

They were told about it over 20 years ago, by the very people who were most likely to exploit it before it became public knowledge...

On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against covert timing channel in CPU cache and translation lookaside buffer (TLB).[23] This analysis was performed under the auspices of the National Security Agency's Trusted Evaluation Program (TPEP).

Re:So AMD processors were faster all along?

[HiThere]

Both chips did branch prediction, AMD just checked address validity before the speculative execution rather than afterwards. This allowed Intel chips to be faster at executing the code by ignoring certain (apparently known) security problems.

But whether it was actually faster or not can be disputed, because Intel is also known to have gamed compilers to disadvantage AMD. In that case they made the AMD chips seem slower by cheating. The question is how many of the benchmarks were done with the altered compilers. And this is where the accusation that Intel made their chips *seem* faster gains validity.