lkml.org 
[lkml]   [2004]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What does tainting actually mean?
Nigel Cunningham wrote:

> Is that true? We can see where the oops occurs. If it's in the module,
> nothing more needs to be said. If it's in the kernel itself, we can
> check our source. We could check all the calls the module makes to open
> source code and validate that the parameters are correct. We should be
> able to say with authority 'the module is doing the wrong thing'. We
> might not be able to say exactly what, but we could determine that it
> is the module.

If only it were that easy.

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.

Generally speaking, if a user is technical enough to patch their kernel, they're aware of the
possible problems and will submit bug reports with things like "kernel version blah, with the foo
and bar patches applied". The developers can then say "there's a known issue with foo/bar together".

Binary modules, on the other hand, are often loaded up by users that know just barely enough to
download them and run an install script. In this case, it can be helpful to know up front that
there has been proprietary code running in kernel space, and aside from calls to kernel APIs, we
have no clue what else it was doing, what memory was being trampled, what cpu registers were
whacked, etc.

Chris
-
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 14:02    [W:0.073 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site