Who needs /dev/kmem?
Who needs /dev/kmem?
Posted Aug 18, 2005 4:04 UTC (Thu) by pengo (guest, #7787)Parent article: Who needs /dev/kmem?
I imagine it would be useful for researchers (security and otherwise) trying to grasp what the overall kernel memory space looks like at any one time. Any such general purpose mechanism is going to have a myriad of unforeseen uses.
As a developer of a hex editor myself, I'd personally be sad to see it go.
Posted Aug 18, 2005 5:23 UTC (Thu)
by mingo (guest, #31122)
[Link]
i think this says it all:
"It has been suggested that root kits are the largest user community for this kind of access, but there are no forward compatibility guarantees for root kit authors."
what would you use /dev/kmem for? If you are interested in runtime kernel internals then you probably want to apply the kgdb patch (or any other kernel debugger), that gives you vastly more options than /dev/kmem.
/dev/kmem has no real use today, other than rootkits - hence the removal from Fedora. It should be removed from mainline too.
Posted Aug 18, 2005 5:28 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (5 responses)
Posted Aug 18, 2005 6:28 UTC (Thu)
by fenrus (guest, #31654)
[Link] (4 responses)
Posted Aug 18, 2005 13:37 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
Basically it should be a kernel debugging option, and thus off for the vast majority of systems.
Posted Aug 19, 2005 0:21 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (2 responses)
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.
Posted Aug 19, 2005 7:50 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (1 responses)
Posted Aug 19, 2005 16:15 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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.
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.
Who needs /dev/kmem?
Most practical applications for /dev/kmem are better served by /proc/kcore, which has the same information, but structured as a core file.Who needs /dev/kmem?
and... more imporantly, a *read only* file.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.Who needs /dev/kmem?
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.
Who needs /dev/kmem?
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?
Who needs /dev/kmem?
If no one is using something, there's no point in it being maintained
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.