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.

Permalink for comment 652446
To read all comments associated with this story, please click here.
RE: Overhyped
by oiaohm on Wed 3rd Jan 2018 08:02 UTC in reply to "Overhyped"
Member since:

Note that the insane hackery to avoid this non-issue adds significant overhead to kernel system calls; ironically, making the performance of monolithic kernels worse than the performance of micro-kernels (while still providing inferior security than micro-kernels). The insane hackery doesn't entirely fix the "problem" either (a small part of kernel must remain mapped, and an attacker can still find out where in kernel space that small part of the kernel is and use this information to infer where the rest of the kernel is).

Please do not claim bogus. Microkernels fixed against this defect will in fact take a higher hit than a monolithic kernel. Kernel to usermode switching cost increases when you have to change complete page tables every single time changing from kernel to userspace and back. Microkernel do this way more often than Monolithic. The advantage of running drivers in kernel space.

This is not exactly a non issue. The fact userspace ring is interfering was able to detect kernel space pages was found in 2016. Now kernel space pages with wrong protective bits for any reason are also exposed due to that fault.

Small fragment mapped of kernel mapped in userspace does not provide enough information to work out the randomisation. Complete kernel mapped into userspace as Intel CPU have been doing down right does.

Small fragment mapped into user-space on independent page tables does not mean there is any relationship of that information once you enter kernel mode and switch to kernel mode TLB.

Also this mapping fix to work around Intel MMU/CPU design issue applied to a Microkernel in fact hurts worst. It some ways it explains why AMD cpu have been slightly slower in particular benchmarks.

Yes AMD MMU/CPU if you attempt to access ring 0 pages from ring 1-3 and they have not been mapped for you its not happening. Same with ring 1 from ring 2 and 3.

So that KASLR attack from 2016 did not work on AMD CPUs. So finding extra protection flaws also have no effect on AMD CPU because the KASLR attack from 2016 does not work. Its not that the AMD has different timing is better page memory rules enforced by hardware so most of the kernel ring 0 pages are basically non existent to the userspace code.

Really this is another reason why in the past it was require by the USA Mil for anything they acquired to come 3 vendors using compatible sockets. So a vendor glitch like this could have been fixed by changing chips.

There is security by obscurity and there is no be there. No be there is better. AMD cpu/mmu is doing no be there so userspace could not see all of the kernel space ring 0 pages and this makes solving the address randomisation of kernel next to impossible.

Intel was depending on obscurity that no one would hunt the memory and find out that complete kernel space pages and userspace pages were in fact exposed to userspace program. Then Intel prayed that memory protection settings would always be enforced and correct. There turned up a few case in 2017 where the memory protections were not always on. So now you have kernel pages exposed to userspace and userspace able to write them how can you say mega failure.

Implementing two page tables one for kernel space and one for userspace is about the only valid way to work around intel goof up. Please note this kind of fault dates back to the 286. All the AMD processors with built in MMU have had different behaviour so preventing the problem.

Reply Parent Score: 3