Sean Sprague writes: > The fact that if a driver returns a fail on detach() then it will not be > unloaded strikes me as being nasty. The phrase "trojan horse" comes to > mind... Whilst I guess that it is not straightforward for the kernel to > "decide" when a manlfunctioning (or malevolent (or just badly coded ;-) > )) driver should be forcibly ejected, I suspect that there should be > some means of achieving this.
That sounds more than a little off to me. First of all, we can rule out malevolent drivers, simply because there's nothing we can do about them at this level. In order to get a new driver into the kernel, you have to have access to the system such that you can rewrite the kernel itself. Once a driver is in there, there are no more protections: driver code can do essentially anything it wants, so the horse is already out of the barn, and trying to unload it is foolish. The damage is done, and you're much better off turning off the power. (That's leaving aside the driver signing mechanism, which is a different kettle of fish.) Similarly, if the driver is "badly coded" and refuses to unload, what do you propose to do about it? We can't just remove the driver from memory -- it likely has callbacks inserted (such as with timeout(9F) and open(9E)) that, when they fire, will cause the system to panic. And these may be coded anywhere, meaning that there's no canonical way to find all of them. Moreover, if the driver really is "bad," the state of the rest of the kernel is unknown. There's no way to know if user data has been corrupted or if the system can continue to run at all. A bad driver can do anything. Again, you're better off restarting the system than trying to force the driver away. After excluding those cases, I'm not sure what _reasonable_ usage cases that actually leaves. Is there actually a reasonable case in which the driver incorrectly refuses to unload, hasn't corrupted any system memory, and has no hidden callbacks or other data structure references into its own memory? And if so, why is it important to support that case, especially given the danger incorrect use would pose, and given that _fixing_ the bug in the driver so that it unloads correctly is probably easier? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
