/ proc / self / maps - 3º pedaço de arquivo mapeado?

Question

Estou executando o Arch linux no meu laptop, que é o kernel 3.12.9 agora. Algo mudou sobre a maneira como o kernel mapeia em um executável vinculado dinamicamente e não consigo descobrir. Aqui está o exemplo:

% /usr/bin/cat /proc/self/maps
...
00400000-0040b000 r-xp 00000000 08:02 1186756             /usr/bin/cat
0060a000-0060b000 r--p 0000a000 08:02 1186756             /usr/bin/cat
0060b000-0060c000 rw-p 0000b000 08:02 1186756             /usr/bin/cat
00d6c000-00d8d000 rw-p 00000000 00:00 0                   [heap]
7f29b3485000-7f29b3623000 r-xp 00000000 08:02 1182988     /usr/lib/libc-2.19.so
...

Minha pergunta é: qual é o terceiro mapeamento de /usr/bin/cat ?

Com base em readelf -l /usr/bin/cat , há um segmento carregável de 0x1f8 bytes que deve ser mapeado em 0x400000. Há um segmento carregável de 0xae10 bytes em 0x60ae10. Essas duas partes do arquivo correspondem ao mapeamento 00400000-0040b000 e ao mapeamento 0060a000-0060b000. Mas o terceiro mapeamento, que afirma estar em um deslocamento de arquivo de 0xb000 bytes, não parece corresponder a nenhum Elf64_Phdr. Na verdade, o cabeçalho elf possui apenas 2 segmentos PT_LOAD.

Eu li através de fs/binfm_elf.c no código-fonte do kernel 3.13.2, e não vejo que o kernel mapeie em nada além de segmentos PT_LOAD. Se eu executar strace -o trace.out /usr/bin/cat /proc/self/maps , não vejo nenhuma mmap() chamadas que seriam mapeadas em uma parte de /usr/bin/cat , para que a terceira parte seja mapeada pelo kernel.

Eu executei o mesmo comando ( cat /proc/self/maps ) em um servidor RHEL que estava executando os patches do kernel 2.6.18 + RH. Isso mostra apenas 2 partes de / usr / bin / cat mapeadas na memória, então isso pode ser novo no kernel 3.x.

    

Answer 1

Eu finalmente percebi isso. O kernel mapeia apenas dois segmentos. A terceira parte é uma parte de uma das duas carregadas pelo kernel. O linker de tempo de execução, o programa chamado no php do INTERP, que é /usr/lib/ld-2.24.so para mim agora, altera as permissões nos mapeamentos usando mprotect() para que haja variáveis globais de leitura / gravação, variáveis globais somente leitura e um segmento de texto de leitura / execução. Você pode ver isso acontecer usando strace , mas é fácil perder, já que é apenas uma única chamada mprotect() .

Não foi uma mudança no kernel que causou isso, foi uma mudança no GNU lib C.

    

Answer 2

Oi eu tive o mesmo confuso como você, eu tinha cavar a internet e encontrar isso, eu acho que esta é a resposta para o seu confuso também. link: link

para shrot:

00400000-0040b000 r-xp 00000000 08:02 1186756             /usr/bin/cat
**use for store text code and const varibles**

0060a000-0060b000 r--p 0000a000 08:02 1186756             /usr/bin/cat
**use for GNU_RELRO relocated info**

0060b000-0060c000 rw-p 0000b000 08:02 1186756             /usr/bin/cat
use for bss data segment

espero que isso seja útil