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

2021-03-31 Thread Michal Hocko
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  
> > > 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


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

2021-03-31 Thread Enrico Weigelt, metux IT consult

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  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
i...@metux.net -- +49-151-27565287


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

2021-03-23 Thread David Hildenbrand

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



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

2021-03-23 Thread Greg Kroah-Hartman
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


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

2021-03-22 Thread Steven Rostedt
On Mon, 22 Mar 2021 11:08:47 +0100
David Hildenbrand  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


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

2021-03-22 Thread Michal Hocko
On Fri 19-03-21 10:14:02, Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM 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.
> 
> 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


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

2021-03-22 Thread David Hildenbrand

On 19.03.21 19:10, Steven Rostedt wrote:

On Fri, 19 Mar 2021 15:34:49 +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.


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



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

2021-03-22 Thread David Hildenbrand

On 19.03.21 18:14, Linus Torvalds wrote:

On Fri, Mar 19, 2021 at 7:35 AM 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.


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



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

2021-03-19 Thread James Troup
Linus Torvalds  writes:

> On Fri, Mar 19, 2021 at 7:35 AM 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.
>
> 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


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

2021-03-19 Thread Steven Rostedt
On Fri, 19 Mar 2021 15:34:49 +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.

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


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

2021-03-19 Thread Sebastian Andrzej Siewior
On 2021-03-19 10:14:02 [-0700], Linus Torvalds wrote:
> On Fri, Mar 19, 2021 at 7:35 AM 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.
> 
> 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


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

2021-03-19 Thread Linus Torvalds
On Fri, Mar 19, 2021 at 7:35 AM 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.

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


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

2021-03-19 Thread David Hildenbrand

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-da...@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
"

--
Thanks,

David / dhildenb



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

2021-03-19 Thread David Hildenbrand
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