Messages in this thread | | | Date | Sun, 29 Mar 1998 13:31:03 +0200 (CEST) | From | MOLNAR Ingo <> | Subject | getting rid of iopl(3) in XFree86 |
| |
On Sat, 28 Mar 1998, Linus Torvalds wrote:
> 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
| |