Hmm. Not much info out there yet about the exact nature of the hardware bug but the software fix looks nasty.
I was going to write a short pice about virtual address management on x86 CPUs but as this has come up here is a bit about it now.
Once an x86 CPU switches into 32/64 bit protected mode early in the boot process it is using virtual addressing and it maps these addesses into physical memory using page tables set up by the OS.
The CPU provides four levels of hardware memory and execution protection but Windows only uses 0 and 3 which it calls kernel and user modes.
On a 32 bit CPU there is 4GB of virtual address space and Windows normally reserves the top 2GB for its own kernel mode code.
When you launch a user mode program Windows creates a process for its thread/s to run in.
A process is like a container and it holds together all the info Windows needs to run a program. This is called the context.
Part of the context describes the virtual address range the process has been allocated.
A process will usuall be given the bottom 2GB of virtual addresses to use for its own private user mode threads. These virtual addresses are mapped into physical memory using page tables stored in the context of the process.
Every process also gets the 2GB of common kernel mode virtual addresses mapped into its range but this range is mapped into physical memory using the kernal mode page tables common to the whole system.
User mode threads cannot access kernel mode addresses directly but they do need to call OS services so the CPU provides a special service call instruction that puts the CPU into kernel mode and executes a predefined service dispatch routine.
The kerel mode address range has to be included in every process address range or Windows would generate an access violation fault every time a system call was made.
Hardware CPU mode protection is the only thing stopping user code from accessing kernel memory so if a bug has compromised this then its a really big deal !
Hope thats clearer than mud ?
