On Wed, 14 Aug 2002, der Mouse wrote:

# That *is* just giving the user process direct access to the hardware,
# which is what I thought you were arguing against.  (I'm not sure what
# you're going on about DMA for, though.)  It exposes practically
# everything about the device to userland, with the possible exception of
# exactly where it lives in the machine's physical address space.

There is no problem, to my mind, with giving a user process EXCLUSIVE
access to a DMA region corresponding to the device in question -- no
more than one process would thus have access to the fb (namely the
process running X).

There could probably be more than one.

The problem, which I believe you have just nailed below, is with
granting generic access to all/much/most of the hardware IN THE WHOLE
SYSTEM.

And that, as you note, is a serious security issue.

The whole point of putting the drivers in the kernel is to allow the
kernel to restrict the range of memory accessed, and to just return a
mappable/pre-mapped range for the X server to bash on.

At least, that's what'd make sense to me...

But I'm not a kernel hacker.  How far off am I?

#
# > The point of using a proper device driver instead of just opening
# > all/much/most of the hardware and memory up to the Xserver is to
# > provide proper control over what process(es) get access to the device
# > registers and whatever memory space is used for DMA operations.
#
# If you're arguing against letting the X server at _other_ devices, I
# agree with you - and if the XFree86 design demands that, I'm glad I
# never went near it, because I'd never stand for anything that
# hair-raisingly insecure.

				--*greywolf;
--
NetBSD: Get Over It.