mbox series

[RFC,0/3] drivers/char: remove /dev/kmem for good

Message ID 20210319143452.25948-1-david@redhat.com (mailing list archive)
Headers show
Series drivers/char: remove /dev/kmem for good | expand

Message

David Hildenbrand March 19, 2021, 2:34 p.m. UTC
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).

David Hildenbrand (3):
  drivers/char: remove /dev/kmem for good
  mm: remove xlate_dev_kmem_ptr()
  mm/vmalloc: remove vwrite()

 Documentation/admin-guide/devices.txt     |   2 +-
 arch/alpha/include/asm/io.h               |   5 -
 arch/arm/configs/dove_defconfig           |   1 -
 arch/arm/configs/magician_defconfig       |   1 -
 arch/arm/configs/moxart_defconfig         |   1 -
 arch/arm/configs/mps2_defconfig           |   1 -
 arch/arm/configs/mvebu_v5_defconfig       |   1 -
 arch/arm/configs/xcep_defconfig           |   1 -
 arch/arm/include/asm/io.h                 |   5 -
 arch/h8300/configs/edosk2674_defconfig    |   1 -
 arch/h8300/configs/h8300h-sim_defconfig   |   1 -
 arch/h8300/configs/h8s-sim_defconfig      |   1 -
 arch/hexagon/configs/comet_defconfig      |   1 -
 arch/hexagon/include/asm/io.h             |   1 -
 arch/ia64/include/asm/io.h                |   1 -
 arch/ia64/include/asm/uaccess.h           |  18 --
 arch/m68k/configs/amcore_defconfig        |   1 -
 arch/m68k/include/asm/io_mm.h             |   5 -
 arch/mips/include/asm/io.h                |   5 -
 arch/openrisc/configs/or1ksim_defconfig   |   1 -
 arch/parisc/include/asm/io.h              |   5 -
 arch/powerpc/include/asm/io.h             |   5 -
 arch/s390/include/asm/io.h                |   5 -
 arch/sh/configs/edosk7705_defconfig       |   1 -
 arch/sh/configs/se7206_defconfig          |   1 -
 arch/sh/configs/sh2007_defconfig          |   1 -
 arch/sh/configs/sh7724_generic_defconfig  |   1 -
 arch/sh/configs/sh7770_generic_defconfig  |   1 -
 arch/sh/configs/sh7785lcr_32bit_defconfig |   1 -
 arch/sh/include/asm/io.h                  |   5 -
 arch/sparc/configs/sparc64_defconfig      |   1 -
 arch/sparc/include/asm/io_64.h            |   5 -
 arch/xtensa/configs/xip_kc705_defconfig   |   1 -
 drivers/char/Kconfig                      |  10 -
 drivers/char/mem.c                        | 231 ----------------------
 include/asm-generic/io.h                  |  11 --
 include/linux/fs.h                        |   2 +-
 include/linux/vmalloc.h                   |   3 +-
 kernel/configs/android-base.config        |   1 -
 mm/ksm.c                                  |   2 +-
 mm/vmalloc.c                              | 113 +----------
 41 files changed, 5 insertions(+), 455 deletions(-)

Comments

David Hildenbrand March 19, 2021, 2:45 p.m. UTC | #1
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
"
Linus Torvalds March 19, 2021, 5:14 p.m. UTC | #2
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
Sebastian Andrzej Siewior March 19, 2021, 5:33 p.m. UTC | #3
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
Steven Rostedt March 19, 2021, 6:10 p.m. UTC | #4
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
James Troup March 19, 2021, 6:55 p.m. UTC | #5
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
David Hildenbrand March 22, 2021, 9:57 a.m. UTC | #6
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.
David Hildenbrand March 22, 2021, 10:08 a.m. UTC | #7
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. :)
Michal Hocko March 22, 2021, 1:34 p.m. UTC | #8
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.
Steven Rostedt March 22, 2021, 3:18 p.m. UTC | #9
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
Greg KH March 23, 2021, 1:16 p.m. UTC | #10
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
David Hildenbrand March 23, 2021, 1:44 p.m. UTC | #11
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
Enrico Weigelt, metux IT consult March 31, 2021, 3:08 p.m. UTC | #12
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
Michal Hocko March 31, 2021, 3:19 p.m. UTC | #13
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