On Sun, 11 Sep 2011 20:53:55 -0400, Thor Lancelot Simon wrote:
On Sun, Sep 11, 2011 at 11:42:33PM +0200, Jean-Yves Migeon wrote:On 11.09.2011 21:07, Thor Lancelot Simon wrote:> Similarly, I am not sure I believe the security justification, mostly > because I don't really see why I should believe that the very complex> memory management code involved in providing the split kernel/user> memory-mapped device driver interface this seems to require is less> likely to have security-critical bugs than a comparatively simple> addition of in-kernel support for a few different virtual disk layouts> than the ones we already have code for. That is true, although you could reuse this argument for pretty much everything else, and let all userland be reimplemened in kernel.No. "X > Y" does not imply "for all X for all Y, X > Y".
You forget one thing though: you do not specify from which interval you pick up X and Y, and that's exactly the problem here.
Some consider that having HTTP (or some of it) parsed in-kernel is ok, others considers that running a network stack inside a kernel is an heresy. Question of design and pragmatism. I am not willing to start again the decade-old "micro kernel vs the rest" debate, but I can understand that some would like to perform things in userland that are done in-kernel otherwise.
Now, given the buggy/murky/untested stuff used for virtual image manipulation through blktap, I sill prefer to see (at least) something buggy running in userland and crashing, rather than having to restart the whole OS just because I fired up a corrupted file image :)
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost