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?
Stack Exchange network consists of 181 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.Visit Stack Exchange
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
It provides access to the system's physical memory.
mem(4) man page explains more about what
Yes -- it could cause all sorts of problems. A reboot should fix you, but bad things can happen very easily. Be careful! :-)
/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 is a tiny CLI utility that mmaps
You can get it in Ubuntu with:
sudo apt-get install busybox
Usage: read 4 bytes from the physical address
sudo busybox devmem 0x12345678
0x9abcdef0 to that address:
sudo busybox devmem 0x12345678 w 0x9abcdef0
/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.
/dev/mem to view and modify regular RAM on kernel v4.9, you must fist:
CONFIG_STRICT_DEVMEM(set by default on Ubuntu 17.04)
nopatkernel command line option for x86
IO ports still work without those.
See also: https://stackoverflow.com/questions/39134990/mmap-of-dev-mem-fails-with-invalid-argument-for-virt-to-phys-address-but-addre/45127582#45127582
If you try to write to RAM instead of a register, the memory may be cached by the CPU: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region-of-address-space-in-linux and I don't see a very portable / easy way to flush it or mark the region as uncacheable:
/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:
volatilevariable on an userland process
devmem2, and watch the userland process react:
virt_to_physand pass it back to userland
devmem2to write to the register
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.
/dev/mem provides access to system's physical memory. The byte addresses in /dev/mem are interpreted as physical addresses.
/dev/kmem is similar to /dev/mem but it does not give access to any physical memory but we can access the kernel's virtual address space.
dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM