Like much of the kernel, most people don't think about the kernel stack until something goes wrong. Several topics have come up recently related to kernel stacks.
Back in June, a critical bug called stack clash
was publicly disclosed by a security research firm. For purposes of this
discussion, the runtime heap typically starts at low addresses and grows up.
The stack starts at high addresses and grows down (shouting "the stack grows
down" is a time honored tradition when working with the stack). The heap is
typically managed by some memory manager (usually your libc malloc) with
explicit calls to
brk to increase the heap size. The program stack grows
automatically as it is used. The logic for determining if an access is part of
the automatic stack or a bogus access is approximately "if it's close enough
to the bottom of the existing stack, it's probably fine. Trust me." As you
might expect, things go poorly if the stack grows next to the heap memory and
starts using that as a stack. Several years ago, the kernel added a guard
page to help mitigate this problem. Instead of immediately growing into the
heap right below the stack, the program would access an unmapped page and
then fault. "page" here refers to a region of memory that is literally a
PAGE_SIZE, typically 4K. The stack clash researchers discovered several
vulnerabilities in userspace programs that allowed a jump of larger than a
PAGE_SIZE, thus defeating the guard page.
The biggest issue with this vulnerability is that it's essentially a design
limitation. There's nothing guaranteeing any behavior to completely mitigate
the problem. Userspace can allocate as much junk on the stack as it wants
alloca to its heart content until it runs out of space. The kernel
added a work around
to increase the gap between the stack and VMAs. The commit text freely admits
this isn't a full fix since it only decreases the chance of some userspace
program managing to grow the stack pointer into another region. The gcc
developers have a proposal
for an actual mitigation by probing the stack at regular intervals to make sure
the guard page gets hit. This does require recompiling programs with the
appropriate flag so the kernel work around is still important to have.
In the self-protection
area, Alexander Popov posted a port of the stackleak plugin from
Grsecurity/PaX. Information leaks from the kernel to userspace can be combined
with other bugs to give full kernel exploits. A common source of information
leaks is copying
stack data to userspace. The stackleak plugin aims to mitigate this by clearing
the stack after each system call, reducing the chance of kernel data getting
leaked to userspace. The plugin part of the stackleak plugin is a gcc plugin
track_stack on functions with a stackframe over a certain size.
track_stack updates the lowest value of the stack pointer. When a system
call finishes, the area between the top of the stack and the lowest stack
pointer is cleared. The Grsecurity/PaX version only included support for x86.
I made a first pass attempt at a version for arm64. Apart from being useful
for full architecture support, this was a helpful exercise to figure out what
assumptions the existing code was making. Hopefully feedback will continue
to come in so the series can make progress towards merging.