lkml.org 
[lkml]   [1998]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectgetting 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

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:4.925 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site