Messages in this thread | | | From | Måns Rullgård <> | Subject | Re: What does tainting actually mean? | Date | Wed, 28 Apr 2004 14:48:30 +0200 |
| |
Theodore Ts'o <tytso@mit.edu> writes:
> 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.
Wouldn't the problem be just as difficult to pin to a certain module even if the source code was open? I prefer open source modules (I have Alpha machines), but I just can't see this argument work.
-- Måns Rullgård mru@kth.se
- 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/
| |