> graphics (and X) _is_ so important that I don't see the problem with
> having a trusted X server.
and even for this there is a technical solution. The main reasons to use
iopl(3) was 'high port access' and cli/sti access to handle broken
hardware. Speed isnt _really_ such a big issue, 1 cycles or 3 cycles per
ioport access really vanishes amongst other latencies, and mmap-able
register sets are quite common already. [NOTE, these mmap-able registers
are still unsafe in 90% of the cases, so we want to hide them from users].
The plan to get rid of iopl(3):
1) extend our current (limited) ioperm() range (ports 0-1024) to ports
0-65535. We couldnt do this so far, due to the outragous size of the IO
bitmap (two pages per thread). Gabriel Paulbert has found a nice trick to
get it done in a 'delayed' fashion. (his hack has inspired the clone()
io-bitmap hack as well). The latest softswitch patches implement Gabriel's
trick, i hope we can get them integrated into 2.3. [I'm also ready to
pester XFree86 people witch patches if such a feature went into the kernel
;)]
2) a kernel-based cli/sti implementation. {=new syscall or ioctl, root can
'switch' into cli/sti mode, and this capability remains even after we have
dropped root priviledges. A thread in cli/sti mode can call the
kernel-based sys_cli() and sys_sti() functions, even when not in iopl(3)
mode}. cli/sti is rarely used in XFree86, mostly used during mode switch
(some cards are volatile beasts). cli/sti is already virtualized within X,
so it's about a 10 lines hack to support Linux's kernel-based cli/sti ...
Using ioperm() instead of iopl(3) reduces the impact of X's hardware
priviledges _greatly_. Most cards would be 100% safe, and maybe some cards
need some theoretical and crazy and hardware-specific exploit. (one needs
to start a busmaster DMA request to overwrite kernel memory... almost
impossible to get this right as at the priviledge level where the exploit
might run we do not have knowledge about virtual->physical mappings, thus
there is no reliable way to DMA some exploit code into the kernel ... yes
the system can crash but thats just a mild D.O.S. attack, not a root
exploit).
I think this is a safe plan to move away XFree86 from the (admittedly
quite dangerous) iopl(3) approach. The other 'root' priviledges X has can
be dropped/isolated properly.
and this also has the nice side effect of controlling cli/sti in a
hard-RT-friendly fashion. (this unexpected side-effect also shows that the
idea itself is robust ;). I bet DosEMU could use a virtualized cli/sti as
well.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu