Further Analyzing The Intel CPU "x86 PTI Issue" On More Systems

[pete910]

May I ask why Ryzen is being benched if the fix is not needed or is it for comparison ?

May have missed where you've stated but, Would it be better to test server chips like Xeon's as that what the main worry is regards the fix?

[fuzz]

May I ask why Ryzen is being benched if the fix is not needed or is it for comparison ?

May have missed where you've stated but, Would it be better to test server chips like Xeon's as that what the main worry is regards the fix?

There is no logical reason -- the press is getting paid off and spinning it to make people believe it.

EDIT: The more times something is said the more it becomes reality to your brain.

[Tomin]

May I ask why Ryzen is being benched if the fix is not needed or is it for comparison ?

Because people want to see it tested. Also while PTI may not be needed on Ryzen, it's enabled by default on all systems including Ryzen for now and it's a security feature that could be used on Ryzen as well. So I think it's still useful to test it on systems like Ryzen that don't have PCID.

May have missed where you've stated but, Would it be better to test server chips like Xeon's as that what the main worry is regards the fix?

Probably, unless you happen to be more interested in how PTI affects performance of other systems than Intel.

I think that the title of this article is a bit stupid. PTI is not the issue here but the performance penalty. PTI itself is a workaround (in addition to being a security feature) to an issue in Intel CPUs.

[kyrios]

Couldn't this bug be addressed by an update of the CPU microcode ?

I see an urgent BIOS update from December 29th for updating the CPU microcode and I wonder if it could have a link with this bug or not :

http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=6WT66

[fuzz]

Because Intel wants to see it tested. Also while PTI may not be needed on Ryzen, it's enabled by default on all systems including Ryzen for now and it's an unneeded security feature that could be used on Ryzen as well.

Fixed

[Tomin]

Fixed

I agree with the latter part, but I don't think Intel's desires made any difference to what Michael chose to test.

[fuzz]

I agree with the latter part, but I don't think Intel's desires made any difference to what Michael chose to test.

Ahh true, I don't think Michael is biased either way .

[Naib]

ok this is odd...

uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=on


cat /proc/cpuinfo
...
bugs : sysret_ss_attrs null_seg cpu_insecure

so as expected bugs = cpu_insecure when pti=on is set YET...



uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=off


cat /proc/cpuinfo
....
bugs : sysret_ss_attrs null_seg cpu_insecure



with pti=off the bug is still declared, its like it isn't being turned off in my test...

[Mark625]

It's security hardening feature, which could be enabled on AMD and ARM-based silicons. It's not a workaround for silicon bug, it's a security feature which is now being enabled by default. Only Intel was proven to have issue in their silicon design, but in general it's a good security feature that could be enabled for more than Intel. The problem as mentioned is the cost of it while entering/exiting syscall or interrupt.

Well that's just ... a misunderstanding of how the kernel handles hardware bugs. And it is exactly a workaround for a silicon bug. This patch could be considered a security hardening feature, but one that is completely unnecessary if the CPU properly isolates Ring 3 (userland) processes from accessing Ring 0 (kernel) memory space. AMD states that their processors operate correctly. There is no reason to believe that ARM processors are vulnerable, either. Therefore neither of them require that the "security hardening" be enabled by default, whereas Intel does need it.

So yes, it could be enabled for non-Intel processors. But the whole reason for having hardware bugs identified by the kernel, depending on the processor in use, is so that the only work-arounds used are those that are proven necessary. Can you imagine if every code-path for hardware bugs was made the default, even if the processor in question did not have all those defects?

Cheers!

[Shevchen]

Okay, I've planned to refresh my system with the next CPU iteration anyway. So I'm chilling with "5% - 30%" performance hit till then and will then (if the industry is sane) a hardware fixed version. Sad day for datacenters and other I/O heavy peeps.