O que é / dev / mem?

Presumivelmente, está de alguma forma relacionado à memória? O que seria

sudo cat /dev/urandom > /dev/mem

Faz? Lixeira toda RAM? Toda a memória virtual que não é do kernel? Nenhuma das acima?

Ele fornece acesso à memória física do sistema.

A mem(4)página do manual explica mais sobre o que /dev/memé.

Sim - isso pode causar todos os tipos de problemas. Uma reinicialização deve corrigi-lo, mas coisas ruins podem acontecer com muita facilidade. Seja cuidadoso! :-)

/ dev / mem fornece acesso à memória física do sistema , não à memória virtual. O espaço de endereço virtual dos kernels pode ser acessado usando / dev / kmem.

É usado principalmente para acessar endereços de memória IO relacionados a hardware periférico, como adaptadores de vídeo.

sudo cat /dev/urandom > /dev/memnão fará nada, já que o sudo elevará o privilégio de gato, mas não o redirecionamento. Você pode fazer sudo sue trabalhar no shell raiz ou usar
sudo dd if=/dev/urandom of=/dev/mem

/dev/memfornece acesso à memória física, ou seja, toda a RAM do sistema, no entanto, isso não significa que ele fornece acesso total de leitura / gravação à RAM (consulte a opção CONFIG_STRICT_DEVMEM neste documento). Observe também que algumas regiões da memória física terão outros dispositivos, como a memória da placa de vídeo, etc. mapeados nela.

Escrever às cegas /dev/memresultará em um comportamento incerto. Aqui está um vídeo do youtube fazendo o mesmo.

Teste com busybox devmem

busybox devmemé um pequeno utilitário CLI que mmaps /dev/mem.

Você pode obtê-lo no Ubuntu com: sudo apt-get install busybox

Uso: leia 4 bytes do endereço físico 0x12345678:

sudo busybox devmem 0x12345678

Escreva 0x9abcdef0para esse endereço:

sudo busybox devmem 0x12345678 w 0x9abcdef0

Fonte: https://github.com/mirror/busybox/blob/1_27_2/miscutils/devmem.c#L85

MAP_SHARED

Ao mmapping /dev/mem, você provavelmente deseja usar:

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

MAP_SHARED faz as gravações irem para a memória física imediatamente, o que facilita a observação e faz mais sentido para as gravações de registro de hardware.

CONFIG_STRICT_DEVMEM e nopat

Para usar /dev/mempara visualizar e modificar a RAM normal no kernel v4.9, você deve primeiro:

• desativar CONFIG_STRICT_DEVMEM(definido por padrão no Ubuntu 17.04)
• passe a nopatopção de linha de comando do kernel para x86

As portas de E / S ainda funcionam sem elas.

Consulte também: https://stackoverflow.com/questions/39134990/mmap-of-dev-mem-fails-with-invalid-argument-for-virt-to-phys-address-but-addre/45127582#45127582

Liberação de cache

Se você tentar gravar na RAM em vez de um registro, a memória poderá ser armazenada em cache pela CPU: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linux e não vejo uma maneira muito portátil / fácil de liberá-lo ou marcar a região como inatingível:

• https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region-of-address-space-in-linux
• https://stackoverflow.com/questions/885658/is-it-possible-to-allocate-in-user-space-a-non-cacheable-block-of-memory-on-li

Então, talvez /dev/memnão possa ser usado com segurança para passar buffers de memória para os dispositivos?

Infelizmente, isso não pode ser observado no QEMU, pois o QEMU não simula caches.

Como testá-lo

Agora a parte divertida. Aqui estão algumas configurações legais:

• Memória do usuário
  • alocar volatilevariável em um processo da terra do usuário
  • obtenha o endereço físico com /proc/<pid>/maps+/proc/<pid>/pagemap
  • o endereço físico com devmem2e observe o processo da terra do usuário reagir:
• Memória Kernelland
  • alocar memória do kernel com kmalloc
  • obter o endereço físico virt_to_physe passá-lo de volta para a terra do usuário
  • modifique o endereço físico com devmem2
  • consulta o valor do módulo do kernel
• Mem IO e dispositivo de plataforma virtual QEMU
  • criar um dispositivo de plataforma com endereços de registro físico conhecidos
  • use devmem2para escrever no registro
  • os relógios printfsaem do dispositivo virtual em resposta

O / dev / mem tradicionalmente fornecia acesso a todo o espaço de endereço físico. Isso inclui ram, mas também inclui dispositivos de E / S mapeados na memória.

Muitos kernels modernos serão configurados com "CONFIG_STRICT_DEVMEM", que restringe / dev / mem apenas aos dispositivos de E / S mapeados na memória.

Escrever lixo aleatório nele é uma péssima idéia, mas exatamente o que acontecerá com a maldade é difícil de prever. O hardware pode responder de maneira imprevisível ao lixo aleatório; as estruturas de memória do kernel corrompidas podem causar um comportamento imprevisível do kernel. Na melhor das hipóteses, eu esperaria uma falha do sistema, na pior das hipóteses, a corrupção de dados ou até a obstrução de hardware não estão fora de questão.

O PS nota que seu comando quando executado como um usuário normal não deve fazer nada, porque o sudo apenas elavora o comando cat, não o redirecionamento.