Re: What does tainting actually mean?

[Chris Friesen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/