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

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 652444
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Overhyped
by Brendan on Wed 3rd Jan 2018 07:40 UTC in reply to "RE[3]: Overhyped"
Member since:


There has to be more to it than that. I mean I'm not saying your analysis is wrong, but it has to be incomplete. Someone has either demonstrated a reliable attack using this exploit to compromise and/or crash affected systems from low privilege user space code, or there is more to it than there appears to be.

No way would everyone issue fixes like this in such a cloak and dagger fashion, especially a fix that causes a significant performance regression, if it wasn't scaring the crap out of some people...

You're right - there's something I've overlooked.

For a sequence like "movzx edi,byte [kernelAddress]" then "mov rax,[buffer+edi*8]", if the page is present, the attacker could find out which cache line (in their buffer) got fetched and use that to determine 5 bits of the byte at "kernelAddress".

With 3 more individual attempts (e.g. with "mov rax,[buffer+4+edi*8]", "mov rax,[buffer+2+edi*8]" and "mov rax,[buffer+1+edi*8]") the attacker could determine the other 3 bits and end up knowing the whole byte.

Note: It's not that easy - with a single CPU the kernel's page fault handler would pollute the caches a little (and could deliberately invalidate or completely pollute caches as a defence) before you can measure which cache line was fetched. To prevent that the attacker would probably want/need to use 2 CPUs that share caches (and some fairly tight synchronisation between the CPUs so the timing isn't thrown off too much).

- Brendan

Edited 2018-01-03 07:40 UTC

Reply Parent Score: 3