> > > It _is_ possible. Check out "capabilities".
> >
> > Whoops, excuse me for being stupid! Should have looked closer...
> >
> > But why on earth do we have this several-hundred-postings thread on this,
> > if it is already possible to disable all the raw access?
> >
> > Is it actually feasible? Which important or often used apps do need raw
> > access?
>
> X
Actually, for X, it can be solved by fine-graining "raw io access" - I
wrote a small module for svgalib, but can be easily used for X as well,
which provides a char device similar to /dev/mem, except that it only
allows access to the range 0xa0000-0xbffff and to all ranges for PCI
regions of devices of class 0x0300 (display devices). In addition the
device has ioctls for inb/outb/inw/outw/inl/outl, which only allow
accessing range 0x3c0-0x3df and PCI regions of display cards.
Making X use this device instead of /dev/mem direct IO is simply a
matter of replacing "/dev/mem" with "/dev/svga" in the source and
changing the definition of outb/etc to do the ioctl, instead of direct
IO (except for some cards, like a few versions of the mach64 which need
other IO ports). There is no performance difference unless IO is used
for acceleration, which is only true with a few cards.
With this, X indeed will have raw access to IO, and will probably be
able to burd video card / monitor. With many cards it can also
crash/lock the system with some programming to the video card. But X (or
any process with such video access) won't be able to directly program
the IDE/SCSI controller, or any other device.
-- Matan Ziv-Av. matan@svgalib.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:20 EST