Presumably it's somehow related to memory? What would

sudo cat /dev/urandom > /dev/mem

do? Trash all RAM? All non-kernel virtual memory? None of the above?

3

5 Answers

It provides access to the system's physical memory.

The mem(4) man page explains more about what /dev/mem is.

Yes -- it could cause all sorts of problems. A reboot should fix you, but bad things can happen very easily. Be careful! :-)

3

/dev/mem provides access to the system's physical memory, not the virtual memory. The kernels virtual address space can be accessed using /dev/kmem.

It's primarily used to access IO memory addresses related to peripheral hardware, like video adapters.

sudo cat /dev/urandom > /dev/mem won't do anything, since sudo will elevate the privilege of cat but not of the redirect. You can either do sudo su and then work in the root shell, or use
sudo dd if=/dev/urandom of=/dev/mem

/dev/mem provides access to physical memory, i.e. all of the RAM in the system, however this doesn't mean that it gives you full read/write access to RAM (see CONFIG_STRICT_DEVMEM option in this document). Also note that some regions of physical memory will have other devices like video card memory, etc. mapped onto it.

Writing blindly to /dev/mem will result in an uncertain behaviour, here is a youtube video doing the same.

Test it out with busybox devmem

busybox devmem is a tiny CLI utility that mmaps /dev/mem.

You can get it in Ubuntu with: sudo apt-get install busybox

Usage: read 4 bytes from the physical address 0x12345678:

sudo busybox devmem 0x12345678

Write 0x9abcdef0 to that address:

sudo busybox devmem 0x12345678 w 0x9abcdef0

Source:

MAP_SHARED

When mmapping /dev/mem, you likely want to use:

open("/dev/mem", O_RDWR | O_SYNC);
mmap(..., PROT_READ | PROT_WRITE, MAP_SHARED, ...)

MAP_SHARED makes writes go to physical memory immediately, which makes it easier to observe, and makes more sense for hardware register writes.

CONFIG_STRICT_DEVMEM and nopat

To use /dev/mem to view and modify regular RAM on kernel v4.9, you must fist:

• disable CONFIG_STRICT_DEVMEM (set by default on Ubuntu 17.04)
• pass the nopat kernel command line option for x86

IO ports still work without those.

See also:

Cache flushing

If you try to write to RAM instead of a register, the memory may be cached by the CPU: and I don't see a very portable / easy way to flush it or mark the region as uncacheable:

So maybe /dev/mem can't be used reliably to pass memory buffers to devices?

This can't be observed in QEMU unfortunately, since QEMU does not simulates caches.

How to test it out

Now for the fun part. Here are a few cool setups:

• Userland memory
  • allocate volatile variable on an userland process
  • get the physical address with /proc/<pid>/maps + /proc/<pid>/pagemap
  • the physical address with devmem2, and watch the userland process react:
• Kernelland memory
  • allocate kernel memory with kmalloc
  • get the physical address with virt_to_phys and pass it back to userland
  • modify the physical address with devmem2
  • query the value from the kernel module
• IO mem and QEMU virtual platform device
  • create a platform device with known physical register addresses
  • use devmem2 to write to the register
  • watch printfs come out of the virtual device in response

/dev/mem traditionally provided access to the entire physical address space. That includes ram but it also includes any memory mapped IO devices.

Many modern kernels will be configured with "CONFIG_STRICT_DEVMEM" which restricts /dev/mem to memory mapped IO devices only.

Writing random garbage to it is a bad idea but exactly what badness will happen is diifcult to predict. Hardware may respond in unpredictable ways to random garbage, corrupted kernel memory structures may cause unpredictable kernel behaviour. At best I would expect a system crash, at worst data corruption or even hardware bricking are not out of the question.

P.S. note that your command when run as a normal user shouldn't do anything, because the sudo only elavates the cat command, not the redirect.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy