kernel: disabling /dev/kmem and /dev/mem

Question

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?

Answer 1

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

• Anthony Lineberry on /dev/mem Rootkits - LJ 8/2009 by Mick Bauer
• Who needs /dev/kmem?

Answer 2

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.

Answer 3

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.

• CONFIG_DEVKMEM: determines whether /dev/kmem is created on boot
• CONFIG_DEVMEM: determines whether /dev/mem is created on boot
• CONFIG_STRICT_DEVMEM: if /dev/mem exists, determines whether access to it is restricted

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.

Answer 4

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...