People have been redacting comments in source code...
Some knew.
It would be helpful for some of the senior members (or one) to do a QUAD (Quick And Dirty) rundown of what this is, and how it affects FreeBSD users... Green Beans, such as myself, could really use it...
I do not fully understand the mechanism myself of what the bug is, but I'll share what I know.
When a process is started, the kernel memory space is mapped into the process memory space. Although it's there, due to flags that are set on the pages occupying the kernel memory, a process cannot directly access it. This is done for performance reasons so the CPU will not have to reload the page table into the translation lookaside buffer (TLB) when a process requests kernel services such as I/O. The reason for this is that a full context switch is expensive because the CPU must switch from one address space to another. With the kernel memory within the process address space, the full context switch is not necessary.
This is a guess, but the bug seems to deal with security checks during speculative execution when performing branch prediction. I do not know how or quite understand the mechanism behind it, but using a side-channel attack, a mitigation technique called Address Space Layout Randomization (ASLR) is rendered ineffective. ASLR is a technique where each time a process is executed, the locations of various components are in random locations within the virtual memory space of that process. So each time a process is executed, things such as program code, shared libs, stack, data, heap, kernel, etc... are in different places. It's up to the loader to resolve this so the program can run. The implications of this is that an attacker can find out the locations of things in memory to press other attacks, primarily return address attacks. But other exploits are possible with the main concern of being able to read kernel memory. Kernel memory is full of sensitive information which is why this is such a big deal.
Here is a link to an image demonstrating ASLR.
http://www.worldnews.easybranches.c...ws-aslr-bug-is-intended-feature-microsoft.jpg
Also, apparently this is considered the mother of all privilege escalation bugs for virtual machine hypervisors.
Now, the current fix is to completely remove the kernel memory space from the process memory map, which completely severs the link between the process and the kernel. So when a process needs kernel services, or an hardware interrupt fires, a full context switch is required. That takes much more time and can incur a performance penalty of 30% or more. An example that I read found that there was a 50% performance hit for
du
. The reason for this is that the TLB and caches are dumped and accesses are performed directly to main memory until the caches fill up. When a process references an address that is within a page that is not in the TLB, two main memory accesses are required: First one for the page table lookup, the second one for the actual memory reference. Since main memory nowadays has an access time of something like 20ns, and cache memory is like two orders of magnitude faster, you are looking at an additional 200 clock cycles of time required for cache misses, which incur a massive performance penalty.
In case anyone is wondering, the TLB is the cache for the memory management unit which resides on the CPU die along with the instruction and data caches. It holds a subset of the page table which maps physical memory addresses to virtual memory addresses.
AMD has come out and said that their processors are not vulnerable to this exploit.
This is my understanding of the situation, which will most likely change when more information becomes available.
EDIT:
Some new info. Apparently the bug is in the memory fetch hardware, does not do security checking for speculative execution, and irrevocably modifies the cache. The memory fetch hardware operates below the microcode and cannot be fixed as it's wired logic. Looks like Intel was cutting corners to save some transistors and gain a small performance increase and it bit them, hard. It seems that AMD chips throws an exception if the memory fetch encounters a security failure, speculative execution or not.
EDIT:
It's a timing attack on the speculative execution for out of order processors. By using the timing, an attacker can determine if something is or isn't in the cache. Somehow, they are able to determine where the kernel is mapped in the process address space and can apparently read that kernel memory as well. And it gets worse. They can also read memory that belongs to other processes. This means that the fix is to completely isolate the pages tables from each other.