| |||||||||||||
|
| |||||||||||||
Who needs /dev/kmem?Who needs /dev/kmem?Posted Aug 18, 2005 13:37 UTC (Thu) by nix (subscriber, #2304)In reply to: Who needs /dev/kmem? by fenrus Parent article: Who needs /dev/kmem?
Andi Kleen and others have pointed out that slamming values straight into kernel memory via /dev/kmem is useful in quick-hack kernel debugging.
Basically it should be a kernel debugging option, and thus off for the vast majority of systems.
(Log in to post comments)
Who needs /dev/kmem? Posted Aug 19, 2005 0:21 UTC (Fri) by giraffedata (subscriber, #1954) [Link] It's not just for debug hacking; other kinds of quick hacks are also made possible. Though I haven't used it yet, I'll keep /dev/kmem around regardless of what the mainstream ends up doing. I should probably use /proc/kcore, but I know it would take a significant amount of effort to learn its format, and probably to write code to interpret it. I could use /dev/mem, but again with a lot of unnecessary extra work.In Linux, we stress serving a diverse audience, so we don't ask "why should we keep this feature?" We ask, "why shouldn't we?" Things get dropped because no one is maintaining them, but not because no one is using them.
Who needs /dev/kmem? Posted Aug 19, 2005 7:50 UTC (Fri) by dvdeug (subscriber, #10998) [Link] If no one is using something, there's no point in it being maintained. And if the main users of a feature are rootkits, then it's a disadvantage to have it around at all.
Who needs /dev/kmem? Posted Aug 19, 2005 16:15 UTC (Fri) by giraffedata (subscriber, #1954) [Link] If no one is using something, there's no point in it being maintained I agree with that, but don't find it relevant here. I.e. it's not relevant whether there's a point to maintaining something; what is relevant is what I said above: whether someone is maintaining it.
if the main users of a feature are rootkits, then it's a disadvantage to have it around at all.This is a common argument that I don't accept. If by "have it around," you mean have it present in kernel.org source trees. Not having it around by choosing not to configure it into your kernel makes sense to me. The basic idea I oppose is fighting black hats by withholding tools they could use from the public. Aside from a basic uneasiness about withholding anything from the public, I also believe it has no significant effect, because if /dev/kmem isn't there already, the cracker will just bring his own. That's what rootkits are all about, after all. In any sensible security system, if a cracker has privilege to read and write /dev/kmem, then he also has privilege to load his own device driver.
|
|
||||||||||||