¿Cómo puedo volcar la memoria completa del sistema?

Después de iniciar VirtualBox, la computadora se volvió lenta y luego se colgó por completo debido a OOM. Por lo general, OOM debería comenzar a matar procesos para liberar espacio, pero esto no sucedió (esta fue la segunda vez que experimenté esto).

Tenía un trabajo importante no guardado en un editor de texto, por lo que esperaba encontrarlo de nuevo en la RAM del sistema después de eliminar todos los procesos en la consola actual usando SysRq+ K. La máquina en cuestión es una computadora portátil con 8 GiB RAM que ejecuta Linux x86_64 3.7.5 con un SSD como disco de destino.

Mi primer intento fue dd if=/dev/mem of=memory, pero esto falló después de leer 1MiB de datos. Luego, lo intenté dd if=/dev/fmem of=memory bs=1M, pero esto se detuvo después de leer 3010461696 bytes (exactamente 2871 MiB). Después de mirar /proc/mtrr(se muestra a continuación), decidí intentar agregar skip=4096. Esto finalmente se ralentizó, leyendo a una velocidad de solo 3 MiB / seg, por lo que lo interrumpí (produciendo un archivo de 5.8 GiB). (al menos los últimos 100 MiB del archivo contienen 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

No pude encontrar los datos que había abierto durante algunas horas en el editor de texto, así que creo que me he saltado algo de memoria mientras hacía un volcado. Entonces, dado mi objetivo (recuperación de datos de programas de espacio de usuario), ¿cuál es el método más eficiente para volcar la memoria del sistema en un archivo? ¿Cuáles son algunos puntos que deben tenerse en cuenta al hacer este volcado?

memory data-recovery ram

— Lekensteyn
fuente

¿Has probado / proc / kmem también? No vale mucho porque cambia mientras lo estás copiando.

— ott--

@ ott-- CONFIG_DEVKMEMestá deshabilitado, al mirar en el código fuente parece permitir el acceso sin restricciones, pero todavía no estoy convencido de que esta sea la mejor manera de hacerlo (¿acceso de IO mem?)

— Lekensteyn

Quizás obtuviste la memoria del editor pero no lo reconociste. Reconstruir estructuras de datos a partir de un volcado de memoria puede ser difícil. Lo primero que deberá hacer es reconstruir el mapeo de la memoria a partir de las estructuras de datos del núcleo (probablemente existan herramientas forenses para eso) para obtener la memoria virtual del proceso que le interesa (lo que probablemente sea se extendió por muchas páginas disjuntas de 4kB en la memoria física). Entonces, el texto puede no estar en un blob consecutivo y puede usar UCS4 u otras representaciones y puede almacenar líneas u otros bloques en fragmentos separados.

— Gilles 'SO- deja de ser malvado'

@Gilles +1, una vez que finalice el proceso, esperaría que el núcleo libere los descriptores de tareas -> olvide todo acerca de su asignación de espacio de direcciones. En cuanto a la representación de datos, puede ser fácilmente un árbol (con suficiente suerte asignada por JVM :)).

— Peter

¿Entonces va a excavar a través de gigabytes de datos buscando unos pocos kb de texto que tal vez ni siquiera estén allí? Aguja, conoce al pajar. En el tiempo que pasó en esto, podría haber vuelto a escribir el texto. Si hubo tanto en primer lugar, entonces debe asegurarse de que su editor de texto esté configurado para guardar periódicamente una copia de seguridad para que no pierda mucho si se bloquea.

— psusi

Respuestas:

Mira este proyecto: foriana

Foriana es (ANALIZADOR de imagen de RAM Ramirense)

entrada: volcado de salida RAM (física): diversa información

La versión 1.0 puede enumerar procesos y módulos del volcado de memoria de los núcleos i386 / x86_64 / arm linux / bsd, y ofrece la opción de leer memoria lineal de los volcados.

Hay un módulo de kernel fmem:

Fmem es un controlador de kernel, que crea un dispositivo / dev / fmem. / dev / fmem se comporta de la misma manera que / dev / mem (acceso directo a la memoria física), pero no tiene los límites que tiene / dev / mem. Es posible volcar toda la memoria física a través de / dev / fmem.

Lo tengo, compilar bastante fácil.

— stackterminator
fuente

El autor de la pregunta lo intentó /dev/fmem.

— Tobu

Es posible que desee utilizar ddrescueun programa similar o similar, que puede omitir datos inaccesibles. dd conv=noerrorpodría ser útil también También revise esta pregunta en superusuario .

Sin embargo, lo más importante es que si te metiste en una situación de OOM, la lentitud probablemente fue causada por el intercambio de páginas del kernel de cualquier otra cosa que no sea la aplicación solicitante. Por lo tanto, si desea sus datos, verifique el intercambio en lugar de /dev/mem: es probable que estén allí. Del mismo modo, si el asesino de OOM no se activa y usted mata los procesos a mano, una vez, por ejemplo, su editor es asesinado primero, el proceso de memoria aún puede pasar algún tiempo para tomar esas páginas.

Como mencionó Gilles en el comentario, los datos pueden estar fácilmente en una estructura especial, por lo que no podrá encontrarlos fácilmente, incluso si logra reconstruir las asignaciones de espacio de direcciones del proceso finalizado y tiene la suerte de encontrar todo lo necesario páginas aún intactas.

— Peterph
fuente

He visto esa respuesta SU antes, así es como encontré fmem. ddrescueno me va a ayudar ya que 256 páginas (1 MiB) es un límite codificado. Esperaría entrar en una condición de OOM, pero el asesino de OOM no se activó ( pastebin.com/DvYTCcRK ). Hace una semana, tuve el mismo problema (todavía Linux 3.7.5, no lo he reiniciado, solo lo suspendí en RAM). No hay archivo / partición de intercambio ya que tengo un SSD. (intercambio = 60 (predeterminado)).

— Lekensteyn