Re: Perform mmap and poll on PUD character devices

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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. Most
syscalls have their own in-kernel implementation nowadays.

Please note that userland implementation helps a lot for debugging and
troubleshooting bugs before moving them to kernel, and may help for
availability too. I have been chasing down a few nasty bugs the last
months in xbdback(4), having the kernel busy looping at SPL_BIO or
panic() on memory allocations isn't quite helpful, even when run under
QEMU with half the kernel already borked.

> Basically, the reasons to put this in userspace really look like
> well-intentioned handwaving to me.

We could discuss the impact of implementing GPL-derived code inside kernel?

> Finally, isn't it possible to simply isolate the server side of a
> Xen block driver in its own domain?  At that point the security of
> the dom0 really depends not at all on whether the virtual block driver
> lives entirely in kernel or is split between the kernel and userspace.

It is possible, Qubes does that (the so called "storage domain").

All problems in computer science can be solved by another level of
indirection, except... too many layers of indirection. Let's be honest,
running half a dozen Linux on a host is funny, you end up carrying
around your own datacenter.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost