Aprendi que o tamanho da pilha padrão para cada processo é limitado a 8 MB e mmap_base é calculado com base no tamanho da pilha em rlimit e valor aleatório. O código abaixo é a função mmap_base que calcula o endereço mmap_base em x86 (linux/include/uapi/asm-generic/resource.h).
static unsigned long mmap_base(unsigned long rnd)
{
unsigned long gap = rlimit(RLIMIT_STACK);
if (gap < MIN_GAP)
gap = MIN_GAP;
else if (gap > MAX_GAP)
gap = MAX_GAP;
return PAGE_ALIGN(TASK_SIZE - gap - rnd);
}
Estou me perguntando e se o tamanho da pilha do programa for maior que 8 MB + valor rnd? Quero dizer, e se o tamanho da pilha crescer acima de mmap_base? Se eu alocar memória de pilha acima de 8 MB, é apenas falha com falha de segmentação? Se o kernel aumentar o tamanho da pilha automaticamente, é possível mover o conteúdo em mmap_base para outros espaços?
O tamanho da pilha do encadeamento principal do processo não pode ultrapassar o limite definido. O valor padrão desse limite é 8 MB. Exceder este limite resultará em uma falha de segmentação e o processo receberá um
SIGSEGV
sinal, por padrão, matando-o. O tamanho máximo da pilha pode ser alteradoulimit -s
antes de iniciar o programa. O kernel não se move pelas áreas de memória (como a área mmap) depois que o programa foi iniciado e não poderia fazê-lo, porque geralmente há ponteiros apontando para essa área que apontariam para endereços errados após a movimentação.No entanto, a verificação de estouro de pilha é executada quando a memória da pilha é acessada, portanto, apenas executar uma grande alocação na pilha ou alterar o valor do ponteiro da pilha não necessariamente aciona uma falha.
Houve alguma conversa no verão de 2017 sobre a possibilidade de explorar esse comportamento. Se algum invasor conseguir enganar um programa para alocar uma grande quantidade de memória, isso pode fazer com que o ponteiro da pilha pule uma área de proteção e aponte para uma área válida, mas diferente. Isso abre oportunidades para alguns truques inteligentes assumirem o controle do processo. Veja este artigo do lwn.net para uma discussão sobre o assunto.