Have you heard how the Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign? This could be the biggest hardware security flaw I’ve ever heard of.
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.
Linux kernel patches (intentionally without comments to obscure the bug) are already going into the kernel sources. Once released, the kernel will still have to make its way into the distributions.
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. Your mileage may vary.
I’ve heard that the performance hit will be worse on older computers.
Similar operating systems, such as Apple’s 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can’t address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.
Microcode is code that runs inside the CPU itself (kind of a meta program), and can be updated with a firmware patch, but in this case, it won’t help. At the moment, you can’t buy an Intel based computer that doesn’t have the bug, though AMD CPUs are safe according to AMD. Intel CPUs are used in most PCs and Macs.
Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes’ virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel.
The transition to the kernel (known as a trap) is quite slow (more than a thousand times slower than a CPU instruction). The kernel needs to save enough information to return control to the process when done, and load enough information to do the job being requested. When done, it must then remove the extra information or at least prevent the user process from accessing it upon return. The bug is essentially that this drop in privilege is being done asynchronously, allowing a brief window where the process can access the kernel’s memory.
Kernel Page Table Isolation patches move the kernel into a completely separate address space, so it’s not just invisible to a running process, it’s not even there at all. The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware.
I.e. more state needs to be saved and restored on every system call.
The public cloud server case is really troubling. Many companies have sensitive software running in public clouds like Amazon’s AWS.
In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cock-up is: AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
Though I have heard a rumour that this may not be 100% true.
It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel’s CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.
And someone has already demonstrated a program that exploits the flaw, so make sure that you apply your security patches as soon as they’re available.
Please reblog this to get the word out.