Início / unix / Perguntas / 474028
Accepted
John P
Asked: 2018-10-09 08:01:11 +0800 CST

Por que algumas bibliotecas e outras partes se repetem na memória virtual do linux com gdb?

  • 772

insira a descrição da imagem aqui

Este é o resultado de olhar para a memória virtual de um processo em gdb; Tenho algumas dúvidas sobre isso:

  1. Por que algumas partes da memória virtual são repetidas? Por exemplo, nosso programa (stack6) e biblioteca libc são repetidos 4 vezes; se eles os dividiram em partes diferentes, então por quê? Por que não apenas colocá-los todos juntos?

  2. O caminho superior (/opt/pro...) é a seção de instruções (seção de texto) da nossa memória virtual e contém apenas as instruções?

  3. Por que os tamanhos das 4 libc's são diferentes? Qual é o problema com o deslocamento, se já temos o tamanho e o endereço inicial, para que serve o deslocamento?

  4. Onde estão as seções de dados, bss, kernel e heap e por que algumas partes da imagem acima não têm informações sobre elas? Existe alguma opção melhor no gdb que realmente mostre todas as partes?

  5. Existe algum programa melhor que o gdb que mostre muito melhor a parte da memória virtual do nosso processo? Eu só quero ter um bom visual de uma memória virtual real, qual programa de depuração fornece o melhor resultado.

As seções que mencionei:

insira a descrição da imagem aqui

linux process

1 respostas

  1. Best Answer

    Há uma informação importante faltando na gdbsaída de 's: as permissões das páginas. (Eles são mostrados no Solaris e no FreeBSD , mas não no Linux.) Você pode vê-los olhando para /proc/<pid>/maps; os mapas para seu exemplo de Protostar mostram

    $ cat /proc/.../maps
08048000-08049000 r-xp 00000000 00:0f 2925       /opt/protostar/bin/stack6
08049000-0804a000 rwxp 00000000 00:0f 2925       /opt/protostar/bin/stack6
b7e96000-b7e97000 rwxp 00000000 00:00 0
b7e97000-b7fd5000 r-xp 00000000 00:0f 759        /lib/libc-2.11.2.so
b7fd5000-b7fd6000 ---p 0013e000 00:0f 759        /lib/libc-2.11.2.so
b7fd6000-b7fd8000 r-xp 0013e000 00:0f 759        /lib/libc-2.11.2.so
b7fd8000-b7fd9000 rwxp 00140000 00:0f 759        /lib/libc-2.11.2.so
b7fd9000-b7fdc000 rwxp 00000000 00:00 0
b7fe0000-b7fe2000 rwxp 00000000 00:00 0
b7fe2000-b7fe3000 r-xp 00000000 00:00 0          [vdso]
b7fe3000-b7ffe000 r-xp 00000000 00:0f 741        /lib/ld-2.11.2.so
b7ffe000-b7fff000 r-xp 0001a000 00:0f 741        /lib/ld-2.11.2.so
b7fff000-b8000000 rwxp 0001b000 00:0f 741        /lib/ld-2.11.2.so
bffeb000-c0000000 rwxp 00000000 00:0f 0          [stack]

    (O exemplo Protostar é executado em uma VM que é fácil de hackear, presumivelmente para tornar os exercícios tratáveis: não há proteção NX e nem ASLR.)

    Você verá acima que o que parece ser mapeamentos repetidos na gdbverdade corresponde a mapeamentos diferentes com permissões diferentes. O segmento de texto é mapeado como somente leitura e executável; o segmento de dados é mapeado como somente leitura; O BSS e o heap são mapeados para leitura e gravação. Idealmente, o segmento de dados, BSS e heap não são executáveis, mas este exemplo não tem suporte a NX, então eles são executáveis. Cada biblioteca compartilhada obtém seu próprio mapeamento para seu segmento de texto, segmento de dados e BSS. O quarto mapeamento é um segmento não legível, não gravável e não executável normalmente usado para proteger contra estouros de buffer (embora, dada a idade do kernel e da biblioteca C usada aqui, isso possa ser algo diferente).

    O deslocamento, quando fornecido, indica o deslocamento dos dados dentro do arquivo, o que não necessariamente tem muito a ver com sua posição no espaço de endereço. Quando carregado, está sujeito a restrições de alinhamento; por exemplo, libc-2.11.2.soos cabeçalhos de programa de ' especificam dois cabeçalhos “LOAD”:

    Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x00000000 0x00000000 0x13d2f4 0x13d2f4 R E 0x1000
LOAD           0x13e1cc 0x0013f1cc 0x0013f1cc 0x027b0  0x0577c  RW  0x1000

    (Use readelf -lpara ver isso.)

    Isso pode resultar em vários mapeamentos no mesmo deslocamento, com endereços virtuais diferentes, se as seções mapeadas para os segmentos tiverem sinalizadores de proteção diferentes. No stack6caso de:

    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD           0x000000 0x08048000 0x08048000 0x00604 0x00604 R E 0x1000
LOAD           0x000604 0x08049604 0x08049604 0x00114 0x00128 RW  0x1000

    (Isso também explica o tamanho pequeno mostrado por proc info mappingsfor stack6: cada cabeçalho solicita menos de 4KiB, com um alinhamento de 4KiB, então ele obtém dois mapeamentos de 4KiB com o mesmo deslocamento em endereços diferentes.)

    Mapeamentos em branco correspondem a mapeamentos anônimos; veja man 5 procpara detalhes. Você precisaria entrar mmappara gdbdeterminar a que eles correspondem.

    Você não pode ver os mapeamentos do kernel (além do legado vsyscallem algumas arquiteturas) porque eles não importam da perspectiva do processo (eles são inacessíveis).

    Não conheço gdbopção melhor, sempre uso /proc/$$/maps.

    Consulte Como os programas são executados: binários ELF para obter detalhes do formato ELF conforme lido pelo kernel e como ele é mapeado para alocações de memória; tem ponteiros para muito mais material de referência.

    • 6

relate perguntas