Предположительно это как-то связано с памятью? Что бы
sudo cat /dev/urandom > /dev/mem делать? Корзина вся ОЗУ? Вся неядерная виртуальная память? Ни один из вышеперечисленных?
Он обеспечивает доступ к физической памяти системы.
Страница mem(4)man объясняет больше о том, что /dev/memесть.
Да, это может вызвать все виды проблем. Перезагрузка должна исправить вас, но плохие вещи могут произойти очень легко. Быть осторожен! :-)
/ dev / mem обеспечивает доступ к физической памяти системы, а не к виртуальной памяти. Виртуальное адресное пространство ядра может быть доступно с помощью / dev / kmem.
Он в основном используется для доступа к адресам памяти ввода-вывода, связанным с периферийным оборудованием, например видеоадаптерами.
sudo cat /dev/urandom > /dev/memничего не сделает, так как sudo повысит привилегию cat, но не редиректа. Вы можете либо сделать sudo suи затем работать в корневой оболочке, либо использовать
sudo dd if=/dev/urandom of=/dev/mem
/dev/memобеспечивает доступ к физической памяти, т. е. ко всей оперативной памяти в системе, однако это не означает, что он предоставляет вам полный доступ для чтения / записи в ОЗУ (см. параметр CONFIG_STRICT_DEVMEM в этом документе). Также обратите внимание, что в некоторых областях физической памяти будут отображаться другие устройства, такие как память видеокарты и т. Д.
Слепое написание /dev/memприведет к неопределенному поведению, вот видео на YouTube, делающее то же самое.
/ dev / mem традиционно предоставляет доступ ко всему физическому адресному пространству. Это включает в себя оперативную память, но также включает любые устройства ввода-вывода, отображаемые в память.
Многие современные ядра будут сконфигурированы с «CONFIG_STRICT_DEVMEM», который ограничивает / dev / mem только для устройств ввода-вывода с отображением в памяти.
Написание случайного мусора - плохая идея, но точно, что случится, трудно предугадать. Аппаратные средства могут непредсказуемым образом реагировать на случайный мусор, поврежденные структуры памяти ядра могут вызывать непредсказуемое поведение ядра. В лучшем случае я ожидал бы сбой системы, в худшем случае не может быть и речи о повреждении данных или даже аппаратном блокировании.
PS обратите внимание, что ваша команда при запуске от имени обычного пользователя не должна ничего делать, потому что sudo уничтожает только команду cat, а не redirect.
Проверьте это с busybox devmem
busybox devmemэто крошечная утилита CLI, которая mmaps /dev/mem.
Вы можете получить его в Ubuntu с помощью: sudo apt-get install busybox
Использование: прочитать 4 байта с физического адреса 0x12345678:
sudo busybox devmem 0x12345678 Пишите 0x9abcdef0по этому адресу:
sudo busybox devmem 0x12345678 w 0x9abcdef0 Источник: https://github.com/mirror/busybox/blob/1_27_2/miscutils/devmem.c#L85
MAP_SHARED
Когда mmapping /dev/mem, вы, вероятно, хотите использовать:
open("/dev/mem", O_RDWR | O_SYNC); mmap(..., PROT_READ | PROT_WRITE, MAP_SHARED, ...) MAP_SHARED заставляет записи идти в физическую память немедленно, что облегчает наблюдение и имеет больше смысла для записи аппаратного регистра.
CONFIG_STRICT_DEVMEM а также nopat
Чтобы использовать /dev/memдля просмотра и изменения обычной оперативной памяти в ядре v4.9, вы должны:
CONFIG_STRICT_DEVMEM(установлено по умолчанию в Ubuntu 17.04)nopatкомандной строки ядра для x86Порты ввода-вывода по-прежнему работают без них.
Смотрите также: https://stackoverflow.com/questions/39134990/mmap-of-dev-mem-fails-with-invalid-argument-for-virt-to-phys-address-but-addre/45127582#45127582
Сброс кеша
Если вы попытаетесь выполнить запись в ОЗУ, а не в регистр, память может быть кэширована ЦП: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linux, и я не вижу очень переносимого / простого способа очистить его или пометить регион как не кэшируемый:
Так, может быть, /dev/memнельзя надежно использовать для передачи буферов памяти на устройства?
К сожалению, в QEMU этого не наблюдается, поскольку QEMU не моделирует кэши.
Как это проверить
Теперь самое интересное. Вот несколько классных настроек:
volatileпеременную в пользовательском процессе/proc/<pid>/maps+/proc/<pid>/pagemapdevmem2, и наблюдайте, как пользовательский процесс реагирует:kmallocvirt_to_physи передать его обратно пользователюdevmem2devmem2для записи в реестрprintfвыходят из виртуального устройства в ответ