Che cos'è / dev / mem?

Presumibilmente è in qualche modo legato alla memoria? Cosa sarebbe

sudo cat /dev/urandom > /dev/mem

fare? Cestinare tutta la RAM? Tutta la memoria virtuale non kernel? Nessuno dei precedenti?

Fornisce accesso alla memoria fisica del sistema.

La mem(4)pagina man spiega di più su cosa /dev/memsia.

Sì, potrebbe causare tutti i tipi di problemi. Un riavvio dovrebbe risolverti, ma le cose brutte possono accadere molto facilmente. Stai attento! :-)

/ dev / mem fornisce l'accesso alla memoria fisica del sistema , non alla memoria virtuale. Lo spazio degli indirizzi virtuali dei kernel è accessibile tramite / dev / kmem.

Viene utilizzato principalmente per accedere agli indirizzi di memoria IO relativi all'hardware periferico, come gli adattatori video.

sudo cat /dev/urandom > /dev/memnon farà nulla, poiché sudo eleverà il privilegio di gatto ma non di reindirizzamento. Puoi fare sudo sue poi lavorare nella shell di root, oppure usare
sudo dd if=/dev/urandom of=/dev/mem

/dev/memfornisce l'accesso alla memoria fisica, cioè tutta la RAM nel sistema, tuttavia ciò non significa che ti dia pieno accesso in lettura / scrittura alla RAM (vedi l'opzione CONFIG_STRICT_DEVMEM in questo documento). Si noti inoltre che alcune regioni della memoria fisica avranno altri dispositivi come la memoria della scheda video, ecc. Mappati su di essa.

Scrivere alla cieca /dev/memcomporterà un comportamento incerto, ecco un video di YouTube che fa lo stesso.

Provalo con busybox devmem

busybox devmemè una piccola utility CLI che mmaps /dev/mem.

Puoi scaricarlo su Ubuntu con: sudo apt-get install busybox

Utilizzo: leggere 4 byte dall'indirizzo fisico 0x12345678:

sudo busybox devmem 0x12345678

Scrivi 0x9abcdef0a quell'indirizzo:

sudo busybox devmem 0x12345678 w 0x9abcdef0

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

MAP_SHARED

Quando si esegue il mmapping /dev/mem, probabilmente si desidera utilizzare:

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

MAP_SHARED fa sì che le scritture vadano immediatamente nella memoria fisica, il che semplifica l'osservazione e ha più senso per le scritture di registro hardware.

CONFIG_STRICT_DEVMEM e nopat

Per utilizzare /dev/memper visualizzare e modificare la RAM normale sul kernel v4.9, è necessario pugno:

• disabilita CONFIG_STRICT_DEVMEM(impostato di default su Ubuntu 17.04)
• passa l' nopatopzione della riga di comando del kernel per x86

Le porte IO funzionano ancora senza quelle.

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

Svuotamento della cache

Se si tenta di scrivere nella RAM anziché in un registro, la memoria potrebbe essere memorizzata nella cache dalla CPU: https://stackoverflow.com/questions/22701352/how-to-flush-the-cpu-cache-for-a-region -of-address-space-in-linux e non vedo un modo molto portatile / semplice per svuotarlo o contrassegnare la regione come invariabile:

• 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

Quindi forse /dev/memnon può essere utilizzato in modo affidabile per passare i buffer di memoria ai dispositivi?

Purtroppo questo non può essere osservato in QEMU, poiché QEMU non simula le cache.

Come provarlo

Adesso per la parte divertente. Ecco alcune fantastiche configurazioni:

• Memoria utente
  • allocare volatilevariabile su un processo userland
  • ottieni l'indirizzo fisico con /proc/<pid>/maps+/proc/<pid>/pagemap
  • l'indirizzo fisico con devmem2e osserva la reazione del processo dell'utente :
• Memoria di Kernelland
  • allocare memoria del kernel con kmalloc
  • ottenere l'indirizzo fisico virt_to_physe restituirlo a userland
  • modificare l'indirizzo fisico con devmem2
  • interrogare il valore dal modulo del kernel
• Dispositivo di piattaforma virtuale IO mem e QEMU
  • creare un dispositivo piattaforma con indirizzi di registro fisici noti
  • usare devmem2per scrivere nel registro
  • guarda printfcome esce dal dispositivo virtuale in risposta

/ dev / mem tradizionalmente fornito l'accesso all'intero spazio degli indirizzi fisici. Ciò include ram ma include anche eventuali IO Device mappati in memoria.

Molti kernel moderni saranno configurati con "CONFIG_STRICT_DEVMEM" che limita / dev / mem solo agli IO Device mappati in memoria.

Scrivere spazzatura a caso è una cattiva idea, ma esattamente quale cattiverà accadrà è difficile da prevedere. L'hardware può rispondere in modo imprevedibile alla spazzatura casuale, strutture di memoria del kernel danneggiate possono causare comportamenti imprevedibili del kernel. Nella migliore delle ipotesi mi sarei aspettato un arresto anomalo del sistema, nel peggiore dei casi la corruzione dei dati o persino il brick dell'hardware non sono fuori discussione.

PS nota che il tuo comando quando eseguito come un normale utente non dovrebbe fare nulla, perché sudo elimina solo il comando cat, non il reindirizzamento.