lkml.org 
[lkml]   [2004]   [Apr]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromMåns_Rullgård <>
SubjectRe: What does tainting actually mean?
DateWed, 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/

\
 
 \ /
  Last update: 2005-03-22 13:02    [from the cache]
©2003-2008