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(-)
--
2.29.2
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/[email protected]
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
"
--
Thanks,
David / dhildenb
On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> writes:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <[email protected]> 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
--
James
On 19.03.21 18:14, Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <[email protected]> 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.
--
Thanks,
David / dhildenb
On 19.03.21 19:10, Steven Rostedt wrote:
> On Fri, 19 Mar 2021 15:34:49 +0100
> David Hildenbrand <[email protected]> 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. :)
--
Thanks,
David / dhildenb
On Fri 19-03-21 10:14:02, Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM David Hildenbrand <[email protected]> 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.
--
Michal Hocko
SUSE Labs
On Mon, 22 Mar 2021 11:08:47 +0100
David Hildenbrand <[email protected]> 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
--
Thanks,
David / dhildenb
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 <[email protected]> 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
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
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 <[email protected]> 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
--
Michal Hocko
SUSE Labs