To view parent comment, click here.
To read all comments associated with this story, please click here.
I find that to be... interesting. I remember reading some time ago that someone had added a similar facility to the Linux kernel -- the ability to take a user-mode process and promote it to kernel mode. The main use, I think, was to speed up system services like X, by reducing the number of times that it had to call into the kernel (as calling into the kernel from outside is apparently quite expensive). I think that a consensus was formed, tho, that promoting random userspace daemons - even if they where known, trusted and system-critical - into kernel space was a really, really terrible idea, for exactly that reason: an X bug become then becomes a kernel bug, and an X exploit becomes a kernel exploit. It's interesting that Microsoft apparently ran into the same problem, thought of the same solution... but opted for raw performance over potential security and stability costs.




Member since:
2005-08-07
The microkernel architecture was used in NT 3.1-3.51, but in NT 4 some performance critical components were moved to kernel-mode (although not into the NT kernel itself, which is a separate module). AFAIK this is when Win32k was born. This move resulted in a big performance improvement, but also in less clean design and some security risks (win32k has been exploited to elevate privileges).
I'm not sure what exactly goes to win32k, but at least some of the usermode GDI functions are thin wrappers that just call their kernel mode counterparts.