Linked by Thom Holwerda on Wed 3rd Jan 2018 00:42 UTC
Intel

A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features - such as PCID - to reduce the performance hit.

That's one hell of a bug.

Thread beginning with comment 652476
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Microcode
by Kochise on Wed 3rd Jan 2018 21:41 UTC in reply to "RE[2]: Microcode"
Kochise
Member since:
2006-03-03

Well, a cpu is not a fpga, the whole logic is not reprogrammable. The microcode allows to modify/patch the isa, but the main 'engine' (composed of the 'alu', the 'execution unit', ...) have to be hardwired somehow.

Good explanation here : http://dsearls.org/courses/C391OrgSys/CPU/CPU.htm

Reply Parent Score: 1

RE[4]: Microcode
by kwan_e on Wed 3rd Jan 2018 21:54 in reply to "RE[3]: Microcode"
kwan_e Member since:
2007-02-18

The microcode allows to modify/patch the isa, but the main 'engine' (composed of the 'alu', the 'execution unit', ...) have to be hardwired somehow.


I would hardly call speculative execution as part of the main engine, since processors can get along fine without it. I would have thought speculative execution would be one of the killer features of modern microcode-based designs.

AMD, at least claims, to not have this security hole hardwired into their processors, so it's not impossible to not hardwire this stuff into the processor as to be unfixable.

Reply Parent Score: 3

RE[5]: Microcode
by Kochise on Wed 3rd Jan 2018 22:57 in reply to "RE[4]: Microcode"
Kochise Member since:
2006-03-03

Well, cpu architecture is private ip and the special recipe, the salt and pepper a company like intel, amd or arm (to name a few) promote as unique and groundbreaking and tremendous and butterflies to put to shame competition.

But not only, it's also tricky engineer stuff to get the job done a little way better, faster, frugalier than the competition. These (speculative) execution units are engraved in stone (well, etched in silicon) and are not subject to change until next architecture iteration.

Just like motor engine, the basic principle remains the same, but that doesn't prevent to have modifications and improvements. Yet if the problem is about the particle exhaustion of the combustion engines, which is common across all the whole industry is doomed.

Edited 2018-01-03 22:58 UTC

Reply Parent Score: 0

RE[5]: Microcode
by Alfman on Wed 3rd Jan 2018 23:02 in reply to "RE[4]: Microcode"
Alfman Member since:
2011-01-28

kwan_e,

That is surprising to me. I'd have thought you'd want to make something like branch prediction modifiable (well, just like other instructions/features) so fixes can be applied.

So my question is, why is the lack of security check hardwired, or why it was designed in such a way that not even a microcode update could fix it?


Microcode is pretty basic and it's main purpose is to transform chaotic CISC instructions into normalized, structured, and predictable RISC ones, which greatly reduces the complexity of execution pipelines. However the pipelines themselves aren't implemented with microcode.

You might envision an architecture where the pipelines are implemented in microcode too, but let's try to examine that approach using a hypothetical example. Assume everything were designed in such a way that microcode could fix everything, including the pipelines. This would resemble more and more a software CPU implementation rather than a hardwired one, it would give us much greater flexibility to fix & improve the CPU after fabrication. This might seem good in many ways, but there are a few issues with it. Software algorithms are always going to be slower than transistors hardwired to produce the logic. A more fundamental problem is that moving all features into software doesn't actually obviate the need for complex and potentially buggy hardware pipelines, those merely gets shifted another layer down because you'll still want speculative branch prediction just to run the software based CPU, which itself is running the target x86 code. Technically it's all feasible, but at what complexity, cost and performance?


I would hardly call speculative execution as part of the main engine, since processors can get along fine without it. I would have thought speculative execution would be one of the killer features of modern microcode-based designs.


Well, I personally don't know whether there's a way for intel to disable speculative execution pipelines on modern intel processors or not, but even if you could, that would be turning off decades worth of faster-than-clockspeed performance bumps. Disabling these features on a modern 2.4GH processor could cause regressions back to the 2.4GH performance of much older processors (like y2k era pentiums).



AMD, at least claims, to not have this security hole hardwired into their processors, so it's not impossible to not hardwire this stuff into the processor as to be unfixable.



Given that AMD's x86 implementation is different from intel's there's no reason a hardware flaw in one must be present on the other. Unfortunately it looks like we'll have to wait until next week at the earliest before we get more details...grr.

Reply Parent Score: 3