Я узнал, что размер стека по умолчанию для каждого процесса ограничен 8 МБ, а mmap_base рассчитывается на основе размера стека в rlimit и случайного значения. Код ниже - это функция mmap_base, которая вычисляет адрес mmap_base в 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);
}
Мне интересно, что если размер стека программы больше 8 МБ+значение RND? Я имею в виду, что если размер стека вырастет выше mmap_base? Если я выделяю стековую память выше 8 МБ, это просто приведет к ошибке сегментации? Если ядро автоматически увеличит размер стека, возможно ли переместить содержимое в mmap_base в другие пространства?
решение1
Размер стека основного потока процесса не может превышать установленный предел. Значение этого предела по умолчанию составляет 8 МБ. Превышение этого предела приведет к ошибке сегментации, и процессу будет отправлен сигнал SIGSEGV
, по умолчанию завершающий его. Максимальный размер стека можно изменить с помощью ulimit -s
перед запуском программы. Ядро не перемещается по областям памяти (например, по области mmap) после запуска программы и не могло бы этого сделать, поскольку обычно существуют указатели, указывающие на эту область, которые будут указывать на неправильные адреса после перемещения.
Однако проверка на переполнение стека выполняется при доступе к памяти стека, поэтому простое выделение большого объема памяти в стеке или иное изменение значения указателя стека не обязательно приведет к возникновению ошибки.
Летом 2017 года были разговоры о возможности эксплуатации этого поведения. Если какой-то злоумышленник может обмануть программу, чтобы выделить большой объем памяти, это может привести к тому, что указатель стека пропустит защитную область и укажет на допустимую, но другую область. Это открывает возможности для некоторых хитрых трюков, чтобы взять под контроль процесс. Смотритеэта статья lwn.netдля обсуждения вопроса.