Intel warns users about Specter-Meltdown patch malfunctions

Do not install Intel patches to fix Specter vulnerabilities on Linux systems.

Intel on Monday warned that you should stop installing the current versions of the patches for Specter ( CVE-2017-5715 ), which Linus Torvalds commented as "utter rubbish."

Specter (checking for border bypass of the CVE-2017-5753 array, injection of the target branch CVE-2017-5715 ) and Meltdown (CVE-2017-5754 - “melts” access to memory pages, is treated with a KPTI patch) are vulnerabilities discovered by researchers earlier this month in many Intel, ARM, and AMD processors used in modern PCs, servers, and smartphones. They can allow attackers to steal your passwords, encryption keys and other personal information.

Since last week, users have begun to report that after installing the security update package released by Intel, they encountered problems that were not there before. For example, spontaneous reboots and other “unpredictable” system behavior.

Recognizing these issues, Intel encouraged OEMs, cloud service providers , system manufacturers, software vendors, and end users to stop installing current versions of updates until the giant chip developed “a solution to address it”.

“Currently, we have identified the root cause of the problems for the Broadwell and Haswell platforms and have made significant strides in developing the solution,” the Intel press release said on Monday.

“Last weekend, we began testing an early version of the updated patch with industry partners. We will publish the final version as soon as testing is completed. "

Meanwhile, in an open email, Linus Torvalds emotionally states that he is dissatisfied with Intel's approach to protecting the Linux kernel from Specter and Meltdown vulnerabilities:

“They do crazy things. They are doing something that does not make sense ... I really do not want these garbage patches to be sent thoughtlessly ... I think we need something better than this garbage. " - said Torvalds.

The use of patches from Intel requires that users manually enable and disable the fix during computer startup, while security fixes for this critical vulnerability must be applied automatically.

This is because the Indirect Branch Restricted Speculation or IBRS, one of the three new hardware patches offered by Intel for the CPU microcode, is so inefficient that it can seriously impact performance. In other words, to prevent poor performance in the tests, Intel suggests users to choose between performance and security.

The whole IBRS_ALL feature to me (Linus Torvalds) very clearly says "Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks. "

Other fixes are Page Table Isolation (pti) against Meltdown and Indirect Branch Prediction Barriers (IBPB), as well as IBRS, against Specter (CVE-2017-5715).

The full text of the Linus Torvalds Intel engineers' call for thought can be found here .

Red Hat, VMware , Lenovo and other vendors decided to revoke the patches due to user complaints. New Intel patches will be available soon. We will update this news after their release.

Earlier we wrote on Habré how much slower your system will be after patches for Specter-Meltdown.

It is worth noting that before the updates from Intel, Google experts released the retpoline software design, which they created to protect against Specter attacks and has less overhead.

Learn more about Retpoline

Intel published server performance test results

Earlier, performance data was provided for client systems, and on January 17 there were results of using systems with security updates on the side of data centers. These results are in accordance with industry standards and are useful, but ultimately more important for customers is their own workloads. To date, server platforms with Intel Xeon Scalable (Skylake) systems with the latest server microarchitecture have been tested.

As expected, the test results show a different impact on performance, which varies depending on specific workloads and configurations. A system with a load that includes more user / kernel privilege changes will have a greater performance degradation.


Benchmark results