| |||||||||||||
|
| |||||||||||||
RCU and Unloadable ModulesRCU and Unloadable ModulesPosted Jan 21, 2007 11:04 UTC (Sun) by ortalo (subscriber, #4654)Parent article: RCU and Unloadable Modules
Non malicious kernel drivers is probably reasonable; but, IMHO, non-malicious kernel modules is not so (depends on the context).
(Log in to post comments)
RCU and Unloadable Modules Posted Jan 26, 2007 1:00 UTC (Fri) by PaulMcKenney (subscriber, #9624) [Link] Certainly malicious kernel modules and drivers could cause arbitrary mischief! But I am curious what added complication you see with non-malicious kernel modules (as opposed to non-malicious kernel drivers.
The rcutorture module is an example of a kernel module that is (more or less) non-malicious, and rcu_barrier() seems to work OK for it.
Please let me know what I am missing!
RCU and Unloadable Modules Posted Jan 26, 2007 21:47 UTC (Fri) by ortalo (subscriber, #4654) [Link] IIRC I posted the comment erroneously (I wanted to post it on the previous article: "KHB: Recovering Device Drivers: From Sandboxing to Surviving").Anyway, my idea was that regular device drivers modules are usually associated with hardware management and loaded according to some hardware-related event (possibly kernel-controlled in the first place). So you can build something where such kernel code could be trusted, even if loaded dynamically. However, with a security orientation, one usually try to refrain from using admnistrator-loadable modules in order to avoid that a successful attack enables the attacker to install kernel level backdoors (nearly impossible to detect).
|
|
||||||||||||