The original post doesn’t say much about the bug, except to link to the paper and slides. Here’s a quick summary. Normally, kernel code needs to copy data from the user address space into the kernel which is done using special functions that handle all the edge conditions (like incorrect pointers, unmapped pages, …), but sometimes Windows cheats and directly accesses user memory. Now you have a new problem. Another thread in userland can modify that memory, so if you read it twice expecting the same value, bad things happen. (If it’s copied into the kernel, the copy isn’t modifiable).
Worth noting that some CPUs don’t share address space (sparc), making this bug less likely on unix, since any attempt to access user memory without copying via the magic function will immediately crash on those platforms.. Not to say impossible, but usually after you’ve gone to the bother of copying data into kernel space, you don’t do it twice. I guess windows will have a hard time running on sparc.
The original post doesn’t say much about the bug, except to link to the paper and slides. Here’s a quick summary. Normally, kernel code needs to copy data from the user address space into the kernel which is done using special functions that handle all the edge conditions (like incorrect pointers, unmapped pages, …), but sometimes Windows cheats and directly accesses user memory. Now you have a new problem. Another thread in userland can modify that memory, so if you read it twice expecting the same value, bad things happen. (If it’s copied into the kernel, the copy isn’t modifiable).
Worth noting that some CPUs don’t share address space (sparc), making this bug less likely on unix, since any attempt to access user memory without copying via the magic function will immediately crash on those platforms.. Not to say impossible, but usually after you’ve gone to the bother of copying data into kernel space, you don’t do it twice. I guess windows will have a hard time running on sparc.