> > Well, there are benefits to being able to mlock memory, in that
> > the driver doesn't have to be the one to track ownership of locked-up
> > pages, plus that way the driver cannot be used to circumvent ulimits.
> well, I don't see taking away ownership from drivers as an advantage.
> It basically means that your application can corrupt the system, which
> is what the separation between kernel and application space wants to
> prevent in the first place.
Right. IMHO a kernelspace driver should care for stuff like memory
allocation for busmaster DMA areas.
Reason: Even when playing the weirdest possible tricks on Linux, there is no
guarantee, that you can get DMA-accessible RAM reliably from there.
For 32 bit systems that should work "fine" (as in it should work, but it is
a horrible kludge), but for 64 Bit (Itanium might get available to the
public some day soon, because WinXP is said to be able to handle it)you need
to allocate RAM in a specific memory segment which is physically mapped into
PCI address space.
This can only be guaranteed by a kernelspace driver, much like handling DMA
for ISA devices needed special calls, because you needed memory below 1MB
physical address as target.
> > the driver isn't duplicating the functions of the kernel mm if the
> > userspace app can do the initial aquisition/freeing.
IMO the userspace app cannot do this reliably - there is no API for it.
> > with a graphics driver; could be useful to have a page that you
> > doodle on with no possibility of swap device delay,
That's another story - that's just locked memory - no problem with that.
But I don't think there's an API to ask for PCI-Bus# XX-mapped RAM.
In the kernel, you can. Anyway I don't advise to have stuff like the
Busmaster-DMA window to be programmable from userspace.
This is a huge security gap, as I'd just find out where the kernel is mapped
(trivial - System.map), put that in the reg, put some program code in the
video meory and then do a screen->mem get operation and voila, I have hacked
the kernel, eventually bypassing security.
Even if the chip doesn't have get capabilities (which seem a strange thing),
you can still read the kernel image which compromises information like the
random pool or keys of crypted filesystems.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
