10

I understand that /dev/kmem and /dev/mem provide access to the memory (i.e. raw RAM) of the system. I am also aware, that /dev/kmem can be completely disabled in kernel and that access can be restricted for /dev/mem.

It seems to me, having raw access to memory can be useful for developers and hackers, but why should I need access to memory through /dev/mem. AFAIK it cannot be disabled in kernel (unlike /dev/kmem). Having access to raw memory that can be potentially abused/exploited seems to me to be just asking for trouble.

Is there some practical use for it? Do any user programs require it to work properly?

5
  • 1
    lwn.net/Articles/147901 suggests that X server could use /dev/mem. Not sure that's still relevant.
    – Mat
    Apr 26, 2014 at 9:00
  • This LJ article suggests the same thing: linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits
    – slm
    Apr 26, 2014 at 9:18
  • Did you disable loadable modules, too? Because that's even more dangerous than /dev/mem. Load a module, run code in kernel mode. And on top of that, hardening against attackers with root access is only worthwhile if there are things that root cannot do, which tends not to be the case in typical installations. Apr 26, 2014 at 23:13
  • @Gilles - I am using cryptographically signed modules. Only modules signed with my private key can be loaded. Apr 27, 2014 at 10:10
  • Additional to STRICT_DEVMEM described in man mem, write access to /dev/mem is disabled by kernel lockdown patches used to support "secure boot" (lockdown can be enabled without secure boot). phoronix.com/…
    – sourcejedi
    Jul 25, 2017 at 21:09

4 Answers 4

6

There's a slide deck from Scale 7x 2009 titled: Undermining the Linux Kernel: Malicious Code Injection via /dev/mem that contained these 2 bullets.

Who needs this?

  • X Server (Video Memory & Control Registers)
  • DOSEmu

From everything I've found from search thus far it would appear that these 2 bullets are the front-runners for legitimate uses.

References

2
  • what if I don't run X server on my server, and thus do not need /dev/mem. Is there a way to disable /dev/mem in the kernel completely? I could only find "Filter access to /dev/mem" (CONFIG_STRICT_DEVMEM). Apr 26, 2014 at 9:44
  • 2
    A modern X server, under Linux, is able to live without /dev/mem, as graphic cards have their own device node. That's the case with i915 for example.
    – jørgensen
    Jun 12, 2014 at 15:38
4

It's worth noting that even if you disabled /dev/mem and /dev/kmem that memory can still be dumped; take a look at man proc to reveal /proc/kcore; it is the systems physical memory. A really good forensics toolkit rekall has a tool that does this already; it dumps the memory (and /boot files) so that they can be analyzed.

As a matter of fact, Ubuntu by default disables /dev/kmem:

There is no modern use of /dev/kmem any more beyond attackers using it to load kernel rootkits. CONFIG_DEVKMEM is set to "n". While the /dev/kmem device node still exists in Ubuntu 8.04 LTS through Ubuntu 9.04, it is not actually attached to anything in the kernel.

Ubuntu doesn't disable /dev/mem because its needed by applications.

Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM).

How to disable /proc/kcore?

Do not enable CONFIG_PROC_KCORE when building the kernel.

How do you disable /dev/mem?

Well, looking over man mem gives us some details about how its created:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

You should be able to just rm -rf /dev/mem; you can disable during kernel build phase by not enabling CONFIG_STRICT_DEVMEM.

How to disable /dev/kmem?

Ensure that CONFIG_DEVKMEM is not enabled upon kernel build.

How to prevent cold-boot attacks?

What if I was able to disable /proc/kcore, /dev/mem, /dev/kmem and then used an encrypted swap partition or didn't use swap at all? Well, your memory could just be freezed and accessed that way. How do you prevent this attack? You encrypt your RAM; how do you encrypt your RAM? You can't. See TRESOR for details.

4
  • I have disabled /dev/kmem in my kernel, and I don't see any /proc/kcore on my system. But I do have /dev/mem, and I would like to disable it. Jul 26, 2017 at 14:40
  • There's typos in this answer. /proc/mem should be /dev/mem, similarly for /proc/kmem.
    – rlf
    Jul 31, 2017 at 14:06
  • @bbb31 nice one. I thought there may have been a possibility that there was something I was missing. If that had been the case then I wanted to give you a chance to clarify.
    – rlf
    Jul 31, 2017 at 16:36
  • "How do you prevent this attack? You encrypt your RAM; how do you encrypt your RAM? You can't." Note: In the future, you should be able to do it (at least on some types of hardware) - it's coming soon! lwn.net/Articles/776688 May 4, 2020 at 11:49
2

As you know, /dev/mem provides access to the physical memory of a running system. /dev/kmem provides access to kernel virtual memory. Both of these character devices can be persistently disabled through kernel configuration options (the code is the most authoritative source of information so it is used for reference). Unsetting the first two options below will disable the corresponding devices.

Depending on your distribution, your current kernel configuration can be seen using something like zless /proc/config.gz or less /boot/config-$(uname -r).

I think the initial intent of /dev/mem was to support interaction with memory-mapped peripherals. The obvious negative security implications of having these virtual devices available (e.g. an attacker being able to on the fly patch the memory of another process or even the kernel) have been known about for at least a decade. Restricting access to /dev/mem has been supported in the mainline kernel since early 2008, /dev/kmem has also been optional since around then too.

A decade ago it seems that X was reliant on /dev/mem, I don't think this is still true. To test the claims about X needing /dev/mem I deleted the virtual device from my laptop yesterday and it has been functioning seemingly perfect since. In 2017 there seems to be no practical use for these devices outside of research and doing development.

From a security perspective it is a good idea to remove these devices. It is still worth noting that a remote attacker, with elevated privileges, can read memory outside of its address space. Memory of other user space applications can be accessed using /proc/<pid>/mem. Kernel memory can be accessed using /proc/kcore.

2

I didn't include /dev/mem on my system from the start. I use Gentoo Linux, so this may come as no surprise, since with this Linux distribution you practically build every package yourself, including the Linux kernel.

I never noticed any problems due to the lack of /dev/mem, even when using X.org X11. Just today I noticed that an emerge of the package x11-drivers/xf86-video-vesa prints a message stating that it requires /dev/mem, like this:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Since I didn't install the VESA driver for the XServer intentionally, or even if so only as a fallback I actually never ever had to use and therefore didn't notice it – until now.

But this proves the point that a) X11 doesn't need /dev/mem anymore, and b) that some X11 video drivers may still do anyway.

Newer video drivers for specific hardware will most likely work without it. Just like modern X.org-X11 (on Gentoo, x11-base/xorg-server) doesn't even have to be suid root anymore, that's what progress looks like...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .