> > I'm really not smart enough to find out. Can you show me how to
> > make use of the aperture driver to lower the securelevel or to perform 
> > tasks normally forbidden when securelevel = 1 ?
> 
> It allows access to space outside of memory, that would normally not
> be allowed for root.

"when the system is 'secure'"  8-)


FWIW, you _can't_ completely fix it; allowing the generality you allow
is impossible to make secure.

In some cases, you can do better:

* for PCI video boards (and any other video boards where you know the
memory and i/o range used by the board), allow access to those bits
only, and have the X server access them as region,offset rather than
as just 'pointer' or 'i/o address'.

* for ISA and EISA video boards (and ones that are indistinguishable,
e.g. VL-bus), your only option for 'security' is to let the X server
get at the standard i/o and memory areas, and only those areas.


Of course, if you turn on 'insecure', you can open up everything,
which means sane performance in the cases where security would
prohibit it.


I've been trying to get the XF86 people to buy into region,offset
addressing (especially for I/O regions for a while), but have only
recently been successful in getting an apparent foot in the door and
lately haven't had time to proselytize it and answer questions about
it adequately.

It's also important for things like other systems, e.g. the alpha,
where you really do want 'tag,region,offset' as arguments to a
function or macro (except in the case where you know you've gotten a
chunk of memory linearly mapped, in which case you can just use
pointers), because who _knows_ what the region and offset are actually
going to 'resolve' into (bit swizzling, etc.).  Bogus systems kludge
around this by using generic PC-like 'inb' and 'outb' and friends on
the alpha.  8-)


cgd