In the advent of code branch, logic errors would occasionally create stack overflows in the kernel. Because the stack is currently placed at the end of the ELF in .bss, and the stack grows down on x86, this eventually causes the stack to grow down into the kernel code. Because of where the stack is positioned, one of the first signs of a stack overflow in the kernel is a panic with a corrupted skull image, but it can also corrupt structures like the IDT, causing triple faults.
In practice, we should not be running applications in kspace, and we generally just need to be cautious of how much stack we use in the kernel, but in x86-64 at least, given
- The very large virtual address space available in x86-64
- The space for the kernel stack is reserved by the linker, not the C code
- The kernel sections can be loaded to arbitrary addresses by the module loader
could the stack be placed far away from the kernel in virtual memory to avoid stack corruption? Furthermore, could intentionally-unmapped reserved pages be placed either side of the stack to catch kernel stack overflows with page faults? If the latter can be achieved, then perhaps the page fault handler can also detect this specific page fault and raise it as a kernel stack overflow, rather than a generic page fault.
In the advent of code branch, logic errors would occasionally create stack overflows in the kernel. Because the stack is currently placed at the end of the ELF in
.bss, and the stack grows down on x86, this eventually causes the stack to grow down into the kernel code. Because of where the stack is positioned, one of the first signs of a stack overflow in the kernel is a panic with a corrupted skull image, but it can also corrupt structures like the IDT, causing triple faults.In practice, we should not be running applications in kspace, and we generally just need to be cautious of how much stack we use in the kernel, but in x86-64 at least, given
could the stack be placed far away from the kernel in virtual memory to avoid stack corruption? Furthermore, could intentionally-unmapped reserved pages be placed either side of the stack to catch kernel stack overflows with page faults? If the latter can be achieved, then perhaps the page fault handler can also detect this specific page fault and raise it as a kernel stack overflow, rather than a generic page fault.