Linked by Thom Holwerda on Mon 18th Jan 2010 16:06 UTC, submitted by fireball
Thread beginning with comment 405142
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
More News »
Sponsored Links



Member since:
2009-02-19
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.