Security → A Massive Intel Hardware Bug May Be on the Horizon | HardOCP

A major hardware flaw appears to have been discovered in Intel CPUs, and bypassing this bug can drastically impact performance. Patching the Intel CPU bug is purported to cause a performance hit of 30-35% on Intel CPUs, while all AMD CPUs are unaffected.

The bug itself could potentially have devastating consequences. It opens up possible security vulnerabilities in Intel CPUs, including large cloud providers and web hosts. The hardware bug causes an Intel CPU to prefetch system memory areas and gain control of any application, in theory allowing for a VM on shared hosting to read and write over another VM. Breaking out of the confines of virtual machines hosted at cloud providers could prove hugely damaging.

TLDR;

Copying from the thread on 4chan

There is evidence of a massive Intel CPU hardware bug (currently under embargo) that directly affects big cloud providers like Amazon and Google. The fix will introduce notable performance penalties on Intel machines (30-35%).

People have noticed a recent development in the Linux kernel: a rather massive, important redesign (page table isolation) is being introduced very fast for kernel standards... and being backported! The "official" reason is to incorporate a mitigation called KASLR... which most security experts consider almost useless. There's also some unusual, suspicious stuff going on: the documentation is missing, some of the comments are redacted (»twitter.com/grsecurity/s ··· 84123649

tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

Impact

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern in some way the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as to 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. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no one on Earth can see it, yet they can pray to it.

These KPTI 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. Really, this shouldn't be needed but clearly there is a flaw in Intel's silicon that allows kernel access protection to be bypassed in some way.

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. This adds an extra overhead, and slows down the computer.

"Context switch"

but wouldn't it take a sophisticated attacker to do this

It can be done in Javascript, that's where the real danger can be.

No, it doesn't sound good.

What I don't know is whether "switching between two separate address spaces" means the same thing as "process switch" at these levels of the OS, semantic-wise.

I know from a while ago that process switches are expensive occurrences. Very expensive.

No they are not the same thing. Context switches occur all the time and modern processors are very efficient at this. A context switch occurs any time a privilege level (IE: processor ring execution level) is changed. Every system call incurs a context switch into the kernel and another exiting. What appears to be changing is what happens during that context switch.

While that indeed looms as "interesting", it's always wise to keep in mind that the sales were in December (the end of the tax year) with new tax regulations looming on the horizon for 2018. I've learned that executive stock sales in December must always be viewed with a number of potential personal-finance factors in mind.

OpenBSD's KARL is some sort of mitigation for this. They implemented it in the release that came out in October.