Messages in this thread | | | From | Ralph Metzler <> | Date | Thu, 20 Nov 2003 14:15:07 +0100 | Subject | Re: Announce: ndiswrapper |
| |
Ingo Oeser writes: > We already have a second-class flavor of open source in the kernel right > now. There are drivers that do "magic value at magic address" in a quite > sophisticated manner. Combine this with firmware load from Windows DLLs > and you basically HAVE closed source, since the driver is on the device > itself and we just invoke it via i2c commands. > > On NVidia drivers we might complain, that we don't see, which kernel > functions are used and for what. On these drivers we don't even see what > is done, since the device can issue DMA at will and thus scribble over > random kernel memory on firmware malfunction. And maybe this scribbling > is not that lethal to Windows for some reasons (e.g. area never used or > reserved area) so it will never be fixed. > > Just have a look at some DVB hardware drivers. As much as I like *what* > is done there, I don't like how it is done.
Those drivers (at least the ones in the kernel right now) cannot issue any DMA from inside the firmware. They also cannot crash the system, only themselves. Basically they are like a separate computer connected via a network-like connection (in this case dual ported RAM). The code controlling the PCI bridge is open.
You are right that if the firmware can do things like initiating DMA transfers this is a big problem. Of course this can also happen with hardware which has bugs in permanently burnt-in microcode or even in the silicon itself.
Regards, Ralph Metzler - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |