mbox series

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

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

Message

David Hildenbrand March 24, 2021, 10:23 a.m. UTC
Let's remove /dev/kmem, which is unused and obsolete. Description from
patch #1:

"
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 disable it: in Ubuntu it has been disabled
for more than 10 years, in Debian since 2.6.31, in Fedora at least starting
with FC3, in RHEL starting with RHEL4, in SUSE starting from 15sp2, and
OpenSUSE has it disabled as well.

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" [4] 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
"

RFC -> v1:
- "drivers/char: remove /dev/kmem for good"
-- Add more details to patch description regarding distributions
- "mm/vmalloc: remove vwrite()"
-- Also remove the nommu variant
- Compile-tested on more archs/configs

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/nommu.c                                |  10 -
 mm/vmalloc.c                              | 118 +----------
 42 files changed, 6 insertions(+), 469 deletions(-)


base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b

Comments

Andrew Morton March 24, 2021, 7:24 p.m. UTC | #1
> Let's remove /dev/kmem, which is unused and obsolete.

I grabbed these.  Silently - the cc list is amazing ;)

I was wondering if it would be better to permanently disable /dev/kmem
in Kconfig along with a comment "if you really want this thing then
email peeps@places with a very good reason why".  Let that ride for a
year or three then blam.

But this is so much more attractive, and it certainly sounds like it's
worth any damage it might cause.

We do tend to think about distros.  I bet there are a number of weird
embedded type systems using /dev/kmem - it's amazing what sorts of
hacks those people will put up with the get something out the door. 
But those systems tend to carry a lot of specialized changes anyway, so
they can just add "revert David's patch" to their pile.
Michal Hocko March 24, 2021, 8:14 p.m. UTC | #2
Acked-by: Michal Hocko <mhocko@suse.com>

for the series.

Thanks!
Education Directorate March 24, 2021, 10:58 p.m. UTC | #3
On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
> 
> > Let's remove /dev/kmem, which is unused and obsolete.
> 
> I grabbed these.  Silently - the cc list is amazing ;)
> 
> I was wondering if it would be better to permanently disable /dev/kmem
> in Kconfig along with a comment "if you really want this thing then
> email peeps@places with a very good reason why".  Let that ride for a
> year or three then blam.
> 
> But this is so much more attractive, and it certainly sounds like it's
> worth any damage it might cause.
> 
> We do tend to think about distros.  I bet there are a number of weird
> embedded type systems using /dev/kmem - it's amazing what sorts of
> hacks those people will put up with the get something out the door. 
> But those systems tend to carry a lot of specialized changes anyway, so
> they can just add "revert David's patch" to their pile.
>


I wonder if we should have the opposite of driver/staging and call it
outgoing, with a big thank you to the users and developers and also
to indicate this feature will be removed in the next (few) merge(s)
cycles. I guess not all code can be accumulated under a single
hierarchy. May not be worth the effort, just thinking out loud.

Balbir Singh
Greg Kroah-Hartman March 25, 2021, 6:46 a.m. UTC | #4
On Thu, Mar 25, 2021 at 09:58:12AM +1100, Balbir Singh wrote:
> On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
> > 
> > > Let's remove /dev/kmem, which is unused and obsolete.
> > 
> > I grabbed these.  Silently - the cc list is amazing ;)
> > 
> > I was wondering if it would be better to permanently disable /dev/kmem
> > in Kconfig along with a comment "if you really want this thing then
> > email peeps@places with a very good reason why".  Let that ride for a
> > year or three then blam.
> > 
> > But this is so much more attractive, and it certainly sounds like it's
> > worth any damage it might cause.
> > 
> > We do tend to think about distros.  I bet there are a number of weird
> > embedded type systems using /dev/kmem - it's amazing what sorts of
> > hacks those people will put up with the get something out the door. 
> > But those systems tend to carry a lot of specialized changes anyway, so
> > they can just add "revert David's patch" to their pile.
> >
> 
> 
> I wonder if we should have the opposite of driver/staging and call it
> outgoing, with a big thank you to the users and developers and also
> to indicate this feature will be removed in the next (few) merge(s)
> cycles. I guess not all code can be accumulated under a single
> hierarchy. May not be worth the effort, just thinking out loud.

That is exactly what drivers/staging/ is being used for, for stuff on
the way out of the kernel.  wimax just left the kernel that way a week
or so ago, we've been doing this for many years now, the fact that no
one has noticed is good as that means that no one has needed the code
removed that way :)

thanks,

greg k-h
Greg Kroah-Hartman March 25, 2021, 6:46 a.m. UTC | #5
On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote:
> 
> > Let's remove /dev/kmem, which is unused and obsolete.
> 
> I grabbed these.  Silently - the cc list is amazing ;)

Thanks, I was going to do so, but your tree is fine with me:

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enrico Weigelt, metux IT consult March 31, 2021, 3:18 p.m. UTC | #6
On 24.03.21 20:24, Andrew Morton wrote:

> We do tend to think about distros.  I bet there are a number of weird
> embedded type systems using /dev/kmem - it's amazing what sorts of
> hacks those people will put up with the get something out the door.

There certainly are (seen lots of such crap), another good reason for
kicking it out asap.

> But those systems tend to carry a lot of specialized changes anyway, so
> they can just add "revert David's patch" to their pile.

Often those kind of people aren't capable of that. If anyone finds such
systems, report them to cert, bsi, fd, ...


--mtx