Presumivelmente, é de alguma forma relacionado à memória? O que seria
sudo cat /dev/urandom > /dev/mem
fazer? Lixeira toda a RAM? Toda memória virtual não-kernel? Nenhuma das opções acima?
Fornece acesso à memória física do sistema.
A página mem(4) man explica mais sobre o que é /dev/mem .
Sim - isso pode causar todos os tipos de problemas. Uma reinicialização deve consertar você, 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/mem não fará nada, já que o sudo elevará o privilégio de cat mas não do redirecionamento. Você pode fazer sudo su e, em seguida, trabalhar no shell raiz ou usar sudo dd if=/dev/urandom of=/dev/mem
/dev/mem fornece acesso à memória física, ou seja, toda a RAM no sistema, no entanto, isso não significa que ele fornece acesso total de leitura / gravação à RAM (consulte a opção CONFIG_STRICT_DEVMEM em este 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 para ela.
Escrever cegamente em /dev/mem resultará em um comportamento incerto, aqui é um vídeo do youtube fazendo o mesmo .
/ dev / mem fornece acesso tradicional a todo o espaço de endereço físico. Isso inclui o RAM, mas também inclui dispositivos IO mapeados na memória.
Muitos kernels modernos serão configurados com "CONFIG_STRICT_DEVMEM", que restringe / dev / mem a dispositivos IO mapeados na memória.
Escrever lixo aleatório é uma má idéia, mas exatamente o que a maldade vai acontecer é difícil de prever. O hardware pode responder de formas imprevisíveis ao lixo aleatório, estruturas corrompidas de memória do kernel podem causar um comportamento imprevisível do kernel. Na melhor das hipóteses, eu esperaria uma falha no sistema, na pior das hipóteses corrupção de dados ou até mesmo hardware bricking não estão fora de questão.P.S. note que seu comando quando executado como um usuário normal não deve fazer nada, porque o sudo apenas elavates o comando cat, não o redirecionamento.
Teste com busybox devmem
busybox devmem é um pequeno utilitário da 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 0x9abcdef0 para esse endereço:
sudo busybox devmem 0x12345678 w 0x9abcdef0
Fonte: link
MAP_SHARED
Quando mmapping /dev/mem , você provavelmente vai querer 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 o /dev/mem para visualizar e modificar a memória RAM regular no kernel v4.9, você deve manipular:
CONFIG_STRICT_DEVMEM (definido por padrão no Ubuntu 17.04) nopat para x86 Os portos de IO ainda funcionam sem esses.
Veja também: link
Cache flushing
Se você tentar gravar na RAM em vez de um registrador, a memória pode ser armazenada em cache pela CPU: link e não vejo uma maneira muito portátil / fácil de liberar ou marcar a região como não encaixável:
Então, talvez /dev/mem não possa ser usado de forma confiável para passar buffers de memória para dispositivos?
Isso não pode ser observado no QEMU, infelizmente, já que o QEMU não simula caches.
Como testar isso
Agora para a parte divertida. Aqui estão algumas configurações legais:
volatile em um processo userland /proc/<pid>/maps + /proc/<pid>/pagemap
devmem2 e observe o processo da área do usuário reagir: kmalloc
virt_to_phys e passe-o de volta à userland devmem2
devmem2 para gravar no registro printf s sair do dispositivo virtual em resposta