Come posso scaricare la memoria di sistema completa?

Dopo aver avviato VirtualBox, il computer è diventato lento e si è bloccato completamente a causa di OOM. Di solito, OOM dovrebbe iniziare a uccidere i processi per liberare spazio, ma ciò non è accaduto (questa era la seconda volta che l'ho sperimentato).

Avevo un lavoro importante non salvato in un editor di testo, quindi speravo di ritrovarlo nella RAM del sistema dopo aver ucciso tutti i processi nella console corrente usando SysRq+ K. La macchina in questione è un laptop con 8 GB di RAM con Linux x86_64 3.7.5 con un SSD come disco di destinazione.

Il mio primo tentativo è stato dd if=/dev/mem of=memory, ma questo non è riuscito dopo aver letto 1 MiB di dati. Successivamente, ho provato dd if=/dev/fmem of=memory bs=1M, ma questo si è fermato dopo aver letto 3010461696 byte (esattamente 2871 MiB). Dopo aver guardato /proc/mtrr(vedi sotto), ho deciso di provare ad aggiungere skip=4096. Questo alla fine ha rallentato, leggendo a una velocità di soli 3 MiB / sec, quindi l'ho interrotto (producendo un file di 5,8 GiB). (almeno gli ultimi 100 MiB del file contengono FFs)

reg01: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size=   64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size=   64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size=  128MB, count=1: uncachable

Non sono riuscito a trovare i dati che avevo aperto per alcune ore nell'editor di testo, quindi credo di aver saltato un po 'di memoria mentre eseguivo un dump. Quindi, dato il mio obiettivo (recupero dei dati dai programmi di userspace), qual è il metodo più efficiente per scaricare la memoria di sistema in un file? Quali sono alcuni punti che devono essere considerati mentre si fa una tale discarica?

memory data-recovery ram

— Lekensteyn
fonte

Hai provato anche / proc / kmem? Non vale molto perché cambia mentre lo stai copiando.

— ott--

@ ott-- CONFIG_DEVKMEMè disabilitato, guardando nel codice sorgente sembra consentire l'accesso senza restrizioni, ma non sono ancora convinto che questo sia il modo migliore per farlo (accesso IO mem?)

— Lekensteyn

Forse hai avuto la memoria dell'editor ma non l'hai riconosciuta. La ricostruzione di strutture di dati da un dump della memoria può essere difficile. La prima cosa che devi fare è ricostruire la mappatura della memoria dalle strutture di dati del kernel (probabilmente ci sono strumenti forensi esistenti per quello) in modo da ottenere la memoria virtuale del processo che ti interessa (che probabilmente sarà sparsi in molte pagine disgiunte da 4kB nella memoria fisica). Quindi il testo potrebbe non trovarsi in un BLOB consecutivo e potrebbe utilizzare UCS4 o altre rappresentazioni e può memorizzare linee o altri blocchi in blocchi separati.

— Gilles 'SO- smetti di essere malvagio' il

@Gilles +1, una volta terminato il processo, mi aspetto che il kernel liberi i descrittori di attività -> dimentica tutto della sua mappatura dello spazio degli indirizzi. Per quanto riguarda la rappresentazione dei dati, può facilmente essere un albero (con abbastanza fortuna allocata da JVM :)).

— peterph,

Quindi esplorerai gigabyte di dati alla ricerca di qualche kb di testo che potrebbe non esserci nemmeno? Ago, incontra il pagliaio. Nel tempo che hai speso per questo, potresti aver semplicemente riscritto il testo. Se in primo luogo c'era molto, allora dovresti assicurarti che l'editor di testo sia configurato per salvare periodicamente un backup in modo da non perdere molto se si blocca.

— psusi,

Risposte:

Controlla questo progetto: foriana

Foriana è (FOrensic Ram Image ANAlyzer)

input: dump dell'output (fisico) della RAM: varie informazioni

La versione 1.0 può elencare processi e moduli dal dump della memoria dei kernel i386 / x86_64 / arm linux / bsd e fornire un'opzione per leggere la memoria lineare dai dump.

C'è un modulo kernel fmem:

Fmem è il driver del kernel, che crea il dispositivo / dev / fmem. / dev / fmem si comporta allo stesso modo di / dev / mem (accesso diretto alla memoria fisica), ma non ha limiti che / dev / mem ha. È possibile scaricare tutta la memoria fisica tramite / dev / fmem.

L'ho usato, compilato abbastanza facile.

— stackterminator
fonte

Il richiedente ha provato /dev/fmem.

— Tobu,

Potresti voler usare ddrescueun programma simile, che può saltare dati inaccessibili. dd conv=noerrorpotrebbe anche essere utile. Controlla anche questa domanda sul superutente .

Ancora più importante, tuttavia, se ti sei imbattuto in una situazione di OOM, la lentezza è stata molto probabilmente causata dal fatto che il kernel scambiava pagine da qualsiasi altra cosa che non fosse l'applicazione richiedente. Quindi, se vuoi i tuoi dati, controlla lo swap invece di /dev/mem- è probabile che siano lì. Allo stesso modo, se il killer OOM non si avvia e tu uccidi i processi a mano, una volta per esempio il tuo editor viene ucciso per primo, il processo affamato di memoria potrebbe ancora avere un po 'di tempo per prendere quelle pagine.

Come menzionato da Gilles nel commento, i dati possono essere facilmente in una struttura speciale, quindi non sarai in grado di trovarli così facilmente anche se riuscirai a ricostruire i mapping dello spazio degli indirizzi del processo ucciso e avrai abbastanza fortuna per trovare tutto il necessario pagine ancora intatte.

— peterph
fonte

Ho visto prima quella risposta SU, ecco come ho trovato fmem. ddrescuenon mi aiuterà poiché 256 pagine (1 MiB) sono un limite hardcoded. Mi aspetterei di entrare in una condizione OOM, ma il killer OOM non ha dato il via ( pastebin.com/DvYTCcRK ). Una settimana fa, ho avuto lo stesso problema (ancora Linux 3.7.5, non ho riavviato, sospeso solo su RAM). Non esiste alcun file / partizione di scambio poiché ho un SSD. (swappiness = 60 (impostazione predefinita)).

— Lekensteyn,