it-swarm-eu.dev

Cos'è / dev / mem?

Presumibilmente è in qualche modo legato alla memoria? Cosa sarebbe

Sudo cat /dev/urandom > /dev/mem

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

38
Paul

Fornisce l'accesso alla memoria fisica del sistema.

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

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

31
Andrew Flanagan

/ dev/mem fornisce accesso alla memoria fisica del sistema , non alla memoria virtuale. È possibile accedere allo spazio degli indirizzi virtuali dei kernel utilizzando/dev/kmem.

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

17
rags

Sudo cat /dev/urandom > /dev/mem non farà nulla, poiché Sudo eleverà il privilegio di cat ma non del reindirizzamento. È possibile eseguire Sudo su e quindi lavorare nella shell di root o utilizzare
Sudo dd if=/dev/urandom of=/dev/mem

/dev/mem fornisce l'accesso alla memoria fisica, cioè tutti i RAM nel sistema, tuttavia ciò non significa che fornisca accesso completo in lettura/scrittura a RAM (vedere l'opzione CONFIG_STRICT_DEVMEM in questo documento). Si noti inoltre che alcune aree della memoria fisica avranno altri dispositivi come la memoria della scheda video, ecc. Mappati su di essa.

Scrivere ciecamente a /dev/mem comporterà un comportamento incerto, qui è un video di youtube che fa lo stesso.

8
Sahil Singh

/ dev/mem ha tradizionalmente fornito l'accesso all'intero spazio dell'indirizzo fisico. Ciò include ram ma include anche tutti i dispositivi IO mappati in memoria.

Molti kernel moderni saranno configurati con "CONFIG_STRICT_DEVMEM" che limita solo i dispositivi/dev/mem alla memoria mappata IO.

Scrivere una spazzatura a caso è una cattiva idea, ma esattamente quello che succederà sarà difficile da prevedere. L'hardware può rispondere in modo imprevedibile alla spazzatura casuale, le strutture di memoria del kernel danneggiate possono causare un comportamento imprevedibile del kernel. Nella migliore delle ipotesi, mi aspetto un arresto anomalo del sistema, nel peggiore dei casi la corruzione dei dati o persino la creazione di hardware non sono fuori questione.

Post scriptum nota che il tuo comando quando viene eseguito come utente normale non dovrebbe fare nulla, perché il Sudo eleva solo il comando cat, non il reindirizzamento.

5
plugwash

Provalo con busybox devmem

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

Puoi farlo in Ubuntu con: Sudo apt-get install busybox

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

Sudo busybox devmem 0x12345678

Scrivi 0x9abcdef0 a 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 la mmapping di /dev/mem, è probabile che si desideri utilizzare:

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

MAP_SHARED rende le scritture passate immediatamente alla memoria fisica, il che rende più semplice l'osservazione e ha più senso per le scritture del registro hardware.

CONFIG_STRICT_DEVMEM E nopat

Per usare /dev/mem per visualizzare e modificare regolarmente RAM sul kernel v4.9, devi pugno:

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

Le porte di I/O funzionano ancora senza quelle.

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

Flusso di cache

Se provi a scrivere su RAM invece di un registro, la memoria potrebbe essere memorizzata nella cache dalla CPU: https://stackoverflow.com/questions/22701352/how-to- flush-the-cpu-cache-per-una-regione-di-indirizzo-spazio-in-linux e non vedo un modo molto portabile/semplice per svuotare o contrassegnare il regione come non memorizzabile:

Quindi forse /dev/mem non può essere usato in modo affidabile per passare i buffer di memoria ai dispositivi?

Questo non può essere osservato in QEMU, purtroppo, poiché QEMU non simula le cache.

Come provarlo

Adesso per la parte divertente. Ecco alcune impostazioni interessanti:

  • Memoria Userland
    • allocare la variabile volatile su un processo userland
    • ottieni l'indirizzo fisico con /proc/<pid>/maps + /proc/<pid>/pagemap
    • l'indirizzo fisico con devmem2 e osserva la reazione del processo userland:
  • Memoria di Kernelland
    • allocare la memoria del kernel con kmalloc
    • prendi l'indirizzo fisico con virt_to_phys e restituiscilo in userland
    • modificare l'indirizzo fisico con devmem2
    • interrogare il valore dal modulo del kernel
  • Dispositivo IO mem e piattaforma virtuale QEMU
    • creare un dispositivo con piattaforma con noti indirizzi di registri fisici
    • usa devmem2 per scrivere nel registro
    • guardare printfs uscire dal dispositivo virtuale in risposta