Slashdot Mirror
Intel Says Newer Chips Also Hit by Unwanted Reboots After Patch (zdnet.com)
Intel says the unexpected reboots triggered by patching older chips affected by Meltdown and Spectre are happening to its newer chips, too. From a report: Intel confirmed in an update late Wednesday that not only are its older Broadwell and Haswell chips tripping up on the firmware patches, but newer CPUs through to the latest Kaby Lake chips are too. The firmware updates do protect Intel chips against potential Spectre attacks, but machines with Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake architecture processors are rebooting more frequently once the firmware has been updated, Intel said. Intel has also updated its original Meltdown-Spectre advisory with a new warning about the stability issues and recommends OEMs and cloud providers test its beta silicon microcode updates before final release. These beta releases, which mitigate the Spectre Variant 2 CVE-2017-5715 attack on CPU speculative execution, will be available next week.
Is Intel developing new chips that don't have this problem?
Of course, but the lead time on CPU development is long. It will be at least a year or two before consumers can buy anything with builtin resistance to Spectre and Meltdown.
Are they going to be slower, too?
The generational improvements will probably offset the losses, so I strongly doubt that will be the case.
Plus, fixed CPUs will not require KPTI anymore, so they will be secure with the "normal" OS-level performance optimizations. Windows and Linux can go back to doing things the pre-Meltdown way if Intel fully addresses their problems.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
The truth is that Meltdown is a patented Intel(TM) only spying method (or almost, but AMD got it right on all its x86 implementations).
More seriously, it is delaying the check for access violation well past the point of no return (from an exploit point of view), it is probably fairly cheap to correct the hardware: you have to go through the TLBs to translate the access from virtual address to physical (and even more complex in a virtual machine), this means matching 36 bits (for current 48 bit virtual addresses, 9 more bits with 5 level page tables), moving back the logic to check for access violation to be simultaneous with the translation or cache access (where it belongs) is not trivial, but a competent team could probably do it in a few weeks (the issue is that the HDL code dates from the PPro, and it may be a black box that nobody understands anymore). It's only a few bits to check in the TLB entry (along the bits that define memory attributes cacheable). The influence on the transistor bugdet, processor frequency, performance, and power consumption is probably not measurable. Meltdown is simply a side channel of excessively optimistic execution past a point which would always result in an access violation.
While they are at it, an access violation should always end up in a page table walk, reloading the TLB entry, otherwise this is a side channel which may indicate the kernel mappings to an attacker. This would also get rid of some cases of spurious access violation: the kernel does not invalidate page tables when it relaxes access permission to a table, another thread which has this page cached actually incurs a useless page fault in which the kernel simply invalidates the offending TLB entry so that it is reloaded after the exception routine terminates.
Now Spectre is another matter, it means basically a complete redesign of the branch prediction logic, which often skimps on the number of address bits used to address the associated caches. One solution is to make a full address match, including address spaces, but I'm not even sure that it would be 100% tight.