[lkml]   [1999]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 3dfx - a security hazard?

    On Thu, 11 Mar 1999, Tigran Aivazian wrote:

    > > It didnt - its a security hazard. Any user with access to it can crash
    > > the entire machine
    > I am probably missing something, but access to both /dev/3dfx and (e.g.)
    > /dev/mem is controlled by filesystem permission rules. Writing garbage to
    > either will crash the entire machine. Why is one a security hazard and
    > another is not?

    The 3dfx can lock the pci bus if fed garbage. The /dev/3dfx driver
    doesn't stop garbage being fed in, and so has no benefit over suid
    glide libs which tickle the hardware directly.

    Imagine if writing a bad byte sequence to /dev/dsp caused your hdd
    to corrupt itself. This is basically the same thing. It's not what
    you expect from a /dev interface, so it gets the thumbs down.

    > I think having 3dfx in the official kernel is a good idea - think about
    > it, if you have a 3dfx card you *will* install 3dfx module, be it
    > hazardous or otherwise. If you do not have 3dfx hardware it is silly
    > to compile the driver when configuring the kernel, thus all hazards
    > avoided automatically.

    The proper way is to have an opengl interface which prevents nasty
    garbage being sent to the 3dfx card. This has numerous other neato
    benefits too, like hardware independence for 3d developers, and an
    already well documented API that ties in nicely with X11 if you're
    looking for that sort of thing.

    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.022 / U:50.232 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site