[lkml]   [1999]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject3Dfx security issues
    Yes, the device driver for the 3Dfx hardware makes it easily possible to
    crash the machine. As you noticed, there are a couple of big
    problems. First, is that it mucks in PCI space. Second, if you send
    random cruft to the MMIO space you can crash the board. This is why I
    have made no effort to put this into standard kernels.

    So, why did I create it and is it any better than setuid? I figured it
    was better than setuid, because the applications getting linked against
    Mesa had no security built into them. Quake would read arbitrary files,
    and it was running setuid to speak to the 3Dfx hardware. So, this
    limited the problem to bad programs crashing the machine as opposed to
    reading and writing arbitrary files.

    Second, the crash problem seems to difficult to work around. For
    example, the original Voodoo Graphics required that you "SNAP"
    vertices. That means subpixel values had to be a multiple of 1/16. If
    you passed unsnapped vertices to the Voodoo Graphics you hung your
    hardware. Glide didn't check for snapping because the performance hit
    was too large. Having /dev/3dfx check for valid data would require all
    of Glide to be in the device. This would cause a big performance drop,
    would bloat the kernel, and can't be done for intellectual property

    It seems that any of the kernel graphics driver projects are moving to
    similar approachs and will have similar problems. The question is
    how can this be handled better within the existing contraints?

    - |Daryll

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.021 / U:7.756 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site