3 ms·
What a nasty bug! I would never have guessed that the order of stack-pointer arithmetic and operations on stack variables mattered. I wonder how much of the gen
by steerablesafe 6y ago
What a nasty bug! I would never have guessed that the order of stack-pointer arithmetic and operations on stack variables mattered. I wonder how much of the generated code must be "pessimized" to be interrupt-safe. This could be an actual pessimization if a section of code is only executed with interrupts turned off (I don't know if this happens within the kernel).
How does this relate to user-space code? Could the same bug manifest is user-space code when handling signals? I don't know much about how exactly signals are delivered and handled in user-space processes.
edit: Now that I think about it red zone in user-space pretty much assumes that the equivalent can't happen there. It appears that red zone is disabled for the kernel precisely because of interrupts. I still wonder how signal handlers interact with the user-space thread's stack.
- bregma 6y agoSignal handlers have their own stack for this very reason. Handling interrupts within the Linux kernel is not really very similar to signal handling in userspace.
- steerablesafe 6y agoFrom the very little research I did signal handlers actually use the same stack as the user-space thread it runs on, unless sigaltstack is used to set up a separate stack. Although it's probably possible for the kernel to adjust the stack pointer over the red-zone before returning to user-space, so the signal handler can run safely.
- wahern 6y agoBy default signal handlers don't use a separate stack; they use the same stack as the process/thread that received the signal. A process/thread must call sigaltstack to install an alternative stack for signal handler execution. So to answer the previous poster's question: yes, AFAICT this bug could have effected userspace code unless there are some other nuances at play.