Messages in this thread | | | Date | Wed, 28 Apr 2004 08:10:09 -0400 | From | Theodore Ts'o <> | Subject | Re: What does tainting actually mean? |
| |
On Wed, Apr 28, 2004 at 03:18:35PM +1000, Nigel Cunningham wrote: > On Wed, 28 Apr 2004 01:19:32 -0400, Chris Friesen <cfriesen@nortelnetworks.com wrote: > > > >There has already been a case mentioned of a binary module that messed > >up something that was only visible once that module was unloaded and > >another one loaded. It all depends totally on usage patterns. > > I don't know what module you're talking about, but surely there must be > something that could be done kernel-side to protect against such problems. > Reference counting or such like? I guess if it was a hardware issue, but > then again that might be an issue with too many assumptions being made > about prior state? Maybe I am being too naive :>
The problem is with corrupted data structures, pointers, etc. An evil/incompetently written driver can screw up data structures long after it has been unloaded. Historically, there was a time when a certain set of propeitary six-letter video company beginning with 'N' and ending with 'a' had serious bugs which would corrupt the kernel and create random kernel panics far removed from the actual source of the problems.
Stack overflows in a badly written device driver can overwrite task structures and cause apparent filesystem problems which are blamed on the hapless filesystem authors instead of where the blame properly lies, namely the device driver author.
The thing we could do kernel-side is to implement full VM protections. This is the microkernel approach; the problem though is the performance overhead of having to go through protection boundaries, setting up kernel-module-specific VM page tables, etc., etc. At some level, if people could implement these propeitary code bases in userspace, then there would be no need to risk corrupting internal data structures, and no need to "taint" the kernel. But usually there are performance reasons why the driver authors choose not to go down that path.
- Ted - 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/
| |