| Message ID | 20210319143452.25948-1-david@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drivers/char: remove /dev/kmem for good | expand |
On 19.03.21 15:34, David Hildenbrand wrote: > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. > > More details / findings in patch #1. Patch #2 and #3 perform minor cleanups > based on removed /dev/kmem support. As some arch maintainers are only cced on patch #2 (grml), patch #1 is https://lkml.kernel.org/r/20210319143452.25948-2-david@redhat.com and the description is: " Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and memory ballooning, I started questioning the existance of /dev/kmem. Comparing it with the /proc/kcore implementation, it does not seem to be able to deal with things like a) Pages unmapped from the direct mapping (e.g., to be used by secretmem) -> kern_addr_valid(). virt_addr_valid() is not sufficient. b) Special cases like gart aperture memory that is not to be touched -> mem_pfn_is_ram() Unless I am missing something, it's at least broken in some cases and might fault/crash the machine. Looks like its existance has been questioned before in 2005 and 2010 [1], after ~11 additional years, it might make sense to revive the discussion. CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by mistake?). All distributions I looked at disable it. 1) /dev/kmem was popular for rootkits [2] before it got disabled basically everywhere. Ubuntu documents [3] "There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits.". RHEL documents in a BZ [5] "it served no practical purpose other than to serve as a potential security problem or to enable binary module drivers to access structures/functions they shouldn't be touching" 2) /proc/kcore is a decent interface to have a controlled way to read kernel memory for debugging puposes. (will need some extensions to deal with memory offlining/unplug, memory ballooning, and poisoned pages, though) 3) It might be useful for corner case debugging [1]. KDB/KGDB might be a better fit, especially, to write random memory; harder to shoot yourself into the foot. 4) "Kernel Memory Editor" hasn't seen any updates since 2000 and seems to be incompatible with 64bit [1]. For educational purposes, /proc/kcore might be used to monitor value updates -- or older kernels can be used. 5) It's broken on arm64, and therefore, completely disabled there. Looks like it's essentially unused and has been replaced by better suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's just remove it. [1] https://lwn.net/Articles/147901/ [2] https://www.linuxjournal.com/article/10505 [3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled [4] https://sourceforge.net/projects/kme/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=154796 "
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: > > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. I'll happily do this for the next merge window, but would really want distros to confirm that they don't enable it. I can confirm that it's certainly not enabled on any of the machines I have, but.. Linus
On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote: > On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: > > > > Let's start a discussion if /dev/kmem is worth keeping around and > > fixing/maintaining or if we should just remove it now for good. > > I'll happily do this for the next merge window, but would really want > distros to confirm that they don't enable it. > > I can confirm that it's certainly not enabled on any of the machines I > have, but.. Debian has CONFIG_DEVKMEM disabled since 2.6.31. > Linus Sebastian
On Fri, 19 Mar 2021 15:34:49 +0100 David Hildenbrand <david@redhat.com> wrote: > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. The last time I used /dev/kmem was in 2003. While in Germany, my home firewall (in the US) got rooted. I could ssh into the box but had no way to shut it down because the rootkit took over all those commands (luckily it still allowed me to become root). I finally killed the box with: # ls -lR / > /dev/kmem ;-) But today I have other means of killing the box (or at least crippling it). Thus, it's obsolete in my book. -- Steve
Linus Torvalds <torvalds@linux-foundation.org> writes: > On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: >> >> Let's start a discussion if /dev/kmem is worth keeping around and >> fixing/maintaining or if we should just remove it now for good. > > I'll happily do this for the next merge window, but would really want > distros to confirm that they don't enable it. FWIW, it's been disabled in Ubuntu for over 10 years now: https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled
On 19.03.21 18:14, Linus Torvalds wrote: > On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: >> >> Let's start a discussion if /dev/kmem is worth keeping around and >> fixing/maintaining or if we should just remove it now for good. > > I'll happily do this for the next merge window, but would really want > distros to confirm that they don't enable it. > Thanks, let's wait if someone speaks up. I'll add any details that come up to patch #1 and resend before the next merge window, properly compile-testing on other archs.
On 19.03.21 19:10, Steven Rostedt wrote: > On Fri, 19 Mar 2021 15:34:49 +0100 > David Hildenbrand <david@redhat.com> wrote: > >> Let's start a discussion if /dev/kmem is worth keeping around and >> fixing/maintaining or if we should just remove it now for good. > > The last time I used /dev/kmem was in 2003. While in Germany, my home > firewall (in the US) got rooted. I could ssh into the box but had no way to > shut it down because the rootkit took over all those commands (luckily it > still allowed me to become root). I finally killed the box with: > > # ls -lR / > /dev/kmem > > ;-) Wonder if "echo c > /proc/sysrq-trigger" already existed and would have worked back then. :)
On Fri 19-03-21 10:14:02, Linus Torvalds wrote: > On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: > > > > Let's start a discussion if /dev/kmem is worth keeping around and > > fixing/maintaining or if we should just remove it now for good. > > I'll happily do this for the next merge window, but would really want > distros to confirm that they don't enable it. SLES (starting from 15sp2) and OpenSUSE kernels have it disabled as well.
On Mon, 22 Mar 2021 11:08:47 +0100 David Hildenbrand <david@redhat.com> wrote: > > Wonder if "echo c > /proc/sysrq-trigger" already existed and would have > worked back then. :) > > Looks like sysrq-c was added in 2005: commit 86b1ae38c0a62 ("kdump: sysrq trigger mechanism for kexec based crashdumps") Thus the answer is "No, it would not have worked back then". -- Steve
On Fri, Mar 19, 2021 at 03:34:49PM +0100, David Hildenbrand wrote: > Let's start a discussion if /dev/kmem is worth keeping around and > fixing/maintaining or if we should just remove it now for good. > > More details / findings in patch #1. Patch #2 and #3 perform minor cleanups > based on removed /dev/kmem support. > > Only compile-tested on x86-64 -- good enough for discussing the general > topic (RFC). I'll gladly take this in my char/misc tree for now, to show up in linux-next to get some testing to see if anyone complains. Let me know if that will help out. thanks, greg k-h
On 23.03.21 14:16, Greg Kroah-Hartman wrote: > On Fri, Mar 19, 2021 at 03:34:49PM +0100, David Hildenbrand wrote: >> Let's start a discussion if /dev/kmem is worth keeping around and >> fixing/maintaining or if we should just remove it now for good. >> >> More details / findings in patch #1. Patch #2 and #3 perform minor cleanups >> based on removed /dev/kmem support. >> >> Only compile-tested on x86-64 -- good enough for discussing the general >> topic (RFC). > > I'll gladly take this in my char/misc tree for now, to show up in > linux-next to get some testing to see if anyone complains. > > Let me know if that will help out. Sure! I'll resend as v1 this week (also removing vwrite() from nommu code in patch #3). Thanks
On 19.03.21 18:33, Sebastian Andrzej Siewior wrote: > On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote: >> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: >>> >>> Let's start a discussion if /dev/kmem is worth keeping around and >>> fixing/maintaining or if we should just remove it now for good. >> >> I'll happily do this for the next merge window, but would really want >> distros to confirm that they don't enable it. >> >> I can confirm that it's certainly not enabled on any of the machines I >> have, but.. > > Debian has CONFIG_DEVKMEM disabled since 2.6.31. SLES, too. (but no idea since when exactly) --mtx
On Wed 31-03-21 17:08:03, Enrico Weigelt, metux IT consult wrote: > On 19.03.21 18:33, Sebastian Andrzej Siewior wrote: > > On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote: > > > On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <david@redhat.com> wrote: > > > > > > > > Let's start a discussion if /dev/kmem is worth keeping around and > > > > fixing/maintaining or if we should just remove it now for good. > > > > > > I'll happily do this for the next merge window, but would really want > > > distros to confirm that they don't enable it. > > > > > > I can confirm that it's certainly not enabled on any of the machines I > > > have, but.. > > > > Debian has CONFIG_DEVKMEM disabled since 2.6.31. > > SLES, too. (but no idea since when exactly) 15-SP2 IIRC