Intel: Meltdown and Spectre bugs also affect Ivy Bridge, Sandy Bridge, Skylake and Kaby Lake systems
In an update following the Meltdown and Spectre revelations, Intel has admitted that the problems also affect newer chips. The company had previously focused its attention -- and that of users -- on Broadwell and Haswell chips, but now company vice president Navin Shenoy has conceded that Ivy Bridge, Sandy Bridge, Skylake and Kaby Lake-based platforms are susceptible.
In rather more positive news, Shenoy also says that good progress has been made in identifying the root cause of the problem. Furthermore, beta microcode should be made available to vendors next week.
See also:
- Microsoft releases confusing patches for AMD systems bricked by Meltdown and Spectre fixes
- Meltdown and Spectre: very few enterprise mobile devices are patched, and many will never be
- Intel promises transparency as Meltdown patch causes reboot problems with Broadwell and Haswell chips
- Intel releases benchmark results detailing Meltdown patch performance slowdown
In a blog post, Shenoy says that "while the firmware updates are effective at mitigating exposure to the security issues, customers have reported more frequent reboots on firmware updated systems." It was during the investigation of these further problems that the great impact of Meltdown and Spectre were discovered.
As part of its promised transparency into the on-going problem, Intel has also released further benchmarks that show the impact of patches. The company continues to insist that impact will be minimal, but adds the caveat that this will be dependent "on specific workloads and configurations." Shenay says that "workloads that incorporate a larger number of user/kernel privilege changes and spend a significant amount of time in privileged mode will be more adversely impacted," and shares the following findings:
- Impacts ranging from 0-2 percent on industry-standard measures of integer and floating point throughput, Linpack, STREAM, server-side Java and energy efficiency benchmarks. These benchmarks represent several common workloads important to enterprise and cloud customers.
- An online transaction processing (OLTP) benchmark simulating modeling a brokerage firm’s customer-broker-stock exchange interaction showed a 4 percent impact. More analytics testing is in process and the results will be dependent on system configuration, test setup and benchmark used.
- Benchmarks for storage also showed a range of results depending on the benchmark, test setup and system configuration:
- For FlexibleIO, a benchmark simulating different types of I/O loads, results depend on many factors, including read/write mix, block size, drives and CPU utilization. When we conducted testing to stress the CPU (100 percent write case), we saw an 18 percent decrease in throughput performance because there was not CPU utilization headroom. When we used a 70/30 read/write model, we saw a 2 percent decrease in throughput performance. When CPU utilization was low (100 percent read case), as is the case with common storage provisioning, we saw an increase in CPU utilization, but no throughput performance impact.
- Storage Performance Development Kit (SPDK) tests, which provide a set of tools and libraries for writing high performance, scalable, user-mode storage applications, were measured in multiple test configurations. Using SPDK iSCSI, we saw as much as a 25 percent impact while using only a single core. Using SPDK vHost, we saw no impact.