More details of this issue are now at https://meltdownattack.com/ There are two different bugs.
It looks like the first bug, known as Meltdown, will require a fix along the lines of keeping separate user mode and kernel mode page tables, and changing the page table base register, CR3, anytime the processor shifts between user and kernel mode, like on every system call and every interrupt. Changing CR3 flushes some cached processor state (like TLBs), and I’m reading the overhead may be in the hundreds of clock cycles. The performance impact is very workload dependent, but for network I/O intensive systems, the performance impact could be as much as 30%.
The basic problem is when the processor does speculative execution down a not taken branch path, it fails to properly apply memory protection. The reports are by using this, it’s possible to indirectly determine the contents of kernel memory from a user process. As all physical memory is mapped into kernel addresses, all memory in all processes is potentially readable to the attacking process. The attack can also cross docker and at least some hypervisor boundaries.
A second related bug, impacts Intel, AMD, and some ARM processors.
It sounds like Amazon and Azure clouds are implementing fixes, as they announced required VM reboots in the coming week, I’m guessing to patch the hypervisors.
From what I read, the kernel mode page table should still be able to have the user space mapped, so it’s not immediately clear there will be any impact (other than performance) on METHOD_NEITHER buffer access. It does seem possible drivers that map kernel memory into a user process addresses may be impacted, although we will have to see what mitigation Microsoft ends up doing.
If arbitrary processes can cause kernel address read accesses, there is the potential for a user process causing accesses to device mapped memory. Some devices will malfunction if their registers are arbitrarily read, causing a potential DoS vulnerability and/or data corruption.
Jan