Como despejar a memória completa do sistema?

Depois de iniciar o VirtualBox, o computador ficou lento e, em seguida, desligou completamente devido ao OOM. Normalmente, o OOM deveria iniciar processos de interrupção para liberar espaço, mas isso não aconteceu (foi a segunda vez que experimentei isso).

Eu tinha um trabalho importante não salvo em um editor de texto, então esperava encontrá-lo na RAM do sistema depois de matar todos os processos no console atual usando o SysRq+ K. A máquina em questão é um laptop com 8 GiB de RAM executando Linux x86_64 3.7.5 com um SSD como disco de destino.

Minha primeira tentativa foi dd if=/dev/mem of=memory, mas isso falhou após a leitura de 1MiB de dados. Em seguida, tentei dd if=/dev/fmem of=memory bs=1M, mas isso parou depois de ler 3010461696 bytes (exatamente 2871 MiB). Depois de olhar /proc/mtrr(mostrado abaixo), decidi tentar adicionar skip=4096. No final das contas, ele ficou mais lento, lendo a uma velocidade de apenas 3 MiB / s, então eu o interrompi (produzindo um arquivo de 5,8 GiB). (pelo menos os últimos 100 MiB do arquivo contêm 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

Como não consegui encontrar os dados que abri por algumas horas no editor de texto, acredito que pulei alguma memória ao fazer um despejo. Portanto, dado meu objetivo (recuperação de dados dos programas do espaço do usuário), qual é o método mais eficiente para despejar a memória do sistema em um arquivo? Quais são alguns pontos que devem ser considerados ao fazer esse despejo?

memory data-recovery ram

— Lekensteyn
fonte

Você já tentou / proc / kmem também? Não vale muito a pena porque muda enquanto você está copiando.

— #

@ ott-- CONFIG_DEVKMEMestá desativado, olhando no código fonte que parecem permitir acesso sem restrições, mas eu ainda não estou convencido de que esta é a melhor maneira de fazê-lo (acesso mem IO?)

— Lekensteyn

Talvez você tenha recebido a memória do editor, mas não a reconheceu. Reconstruir estruturas de dados de um despejo de memória pode ser difícil. A primeira coisa que você precisa fazer é reconstruir o mapeamento da memória a partir das estruturas de dados do kernel (provavelmente existem ferramentas forenses existentes) para obter a memória virtual do processo no qual você está interessado (o que provavelmente será espalhadas por muitas páginas separadas de 4kB na memória física). O texto pode não estar em um blob consecutivo e pode usar o UCS4 ou outras representações e pode armazenar linhas ou outros blocos em blocos separados.

— Gilles 'SO- stop be evil'

@Gilles +1, uma vez que o processo é encerrado, eu esperaria que o kernel liberasse os descritores de tarefas -> esqueça tudo sobre o mapeamento do espaço de endereço. Quanto à representação dos dados, ela pode ser facilmente uma árvore (com sorte suficiente alocada pela JVM :)).

— Peterph

Então você vai procurar por gigabytes de dados procurando alguns kb de texto que talvez nem estejam lá? Agulha, encontre palheiro. No tempo que você gastou nisso, você poderia apenas redigitar o texto. Se houver muito disso em primeiro lugar, verifique se o editor de texto está configurado para salvar periodicamente um backup, para não perder muito se ele travar.

— Psusi

Respostas:

Confira este projeto: foriana

Foriana é (ANAlyzer de imagem ram ramificada)

entrada: despejo de saída RAM (física): várias informações

A versão 1.0 pode listar processos e módulos do despejo de memória dos kernels i386 / x86_64 / arm linux / bsd e fornece uma opção para ler a memória linear dos despejos.

Existe um módulo do kernel fmem:

O Fmem é um driver do kernel, que cria o dispositivo / dev / fmem. / dev / fmem se comporta da mesma maneira que / dev / mem (acesso direto à memória física), mas não tem limites que / dev / mem. É possível despejar toda a memória física por meio de / dev / fmem.

Eu tenho usá-lo, compilar muito fácil.

— stackterminator
fonte

O autor da pergunta tentou /dev/fmem.

— Tobu

Você pode usar ddrescueum programa semelhante, que pode ignorar dados inacessíveis. dd conv=noerrorpode ser útil também. Verifique também esta pergunta no superusuário .

Mais importante, porém, se você entrar em uma situação de OOM, é muito provável que a lentidão seja causada pela troca de páginas do kernel de qualquer outra coisa além do aplicativo solicitante. Portanto, se você deseja seus dados, verifique a troca em vez de /dev/mem- é provável que esteja lá. Da mesma forma, se o assassino do OOM não entrar em ação e você matar os processos manualmente, uma vez que, por exemplo, seu editor seja morto primeiro, o processo com fome de memória ainda poderá levar algum tempo para acessar essas páginas.

Conforme mencionado por Gilles no comentário, os dados podem estar facilmente em alguma estrutura especial; portanto, você não poderá encontrá-los facilmente, mesmo que consiga reconstruir os mapeamentos de espaço de endereço do processo morto e tenha sorte suficiente para encontrar todo o necessário páginas ainda intactas.

— peterph
fonte

Eu já vi essa SU responder antes, foi assim que encontrei o fmem. ddrescuenão vai me ajudar, já que 256 páginas (1 MiB) é um limite codificado. Eu esperaria entrar em uma condição OOM, mas o assassino do OOM não entrou em ação ( pastebin.com/DvYTCcRK ). Há uma semana, tive o mesmo problema (ainda o Linux 3.7.5, não reinicializei, apenas suspendi o ram). Não há arquivo / partição de swap, pois tenho um SSD. (swappiness = 60 (padrão)).

— 22413 Lekensteyn