> Wouldn't this kind of issue validate the ideas of microkernel-based OSs, where kernel and user spaces are already completely separated? I don't think so, but

> Wouldn't this kind of issue validate the ideas of microkernel-based OSs, where kernel and user spaces are already completely separated? I don't think so, but it depends what you mean. Kernel space and user space being separated isn't specific to a microkernel. The only reason the kernel is mapped in to each process is to avoid the TLB flush during syscalls. The pages themselves aren't actually accessible unless you're running in kernel mode (well, unless you're using hardware affected by this bug). So, in a non-broken system, kernel and user spaces are separated, even with a monolithic kernel (Linux). > BTW, removing the kernel from the non-privileged address space seems like such a great idea (which is not a new one at all) the whole thing should probably should have some hardware support to be made fast. For the most part, I agree. However, it really shouldn't be necessary if the virtual memory protection did what it was supposed to do. Mapping the kernel in to the process address space and using the page protection flags is an optimization that is perfectly legal from an architectural standpoint. If you can't rely on the page protection flags to work, then you really can't rely on any other hardware feature to work either.