On Wed, 26 Apr 2023, Michael Schmitz wrote:
It seems I got confused about user and kernel stack there myself. And
managed to confuse almost everyone else about this bug. Apologies for
the incessant noise.
Likewise... I think it amuses some readers and annoys others ;-)
What matters for the return from exception is an intact frame on the
kernel stack. Anything we do on the user stack (mucking around with the
offset the sigframe is set up at, copying siginfo, ucontext or
sigcontext plus exception frame extra) does not change the kernel stack
one whit.
The mangle_kernel_stack stuff is needed because sys_sigreturn will place
another exception frame on the kernel stack (a four word frame) that
needs to be replaced by the bus error exception frame (or any other
frame that caused the kernel mode entry prior to signal delivery) before
finally returning from the bus error exception.
Only at that time will the movel instruction that took the bus fault
resume (and complete its writes correctly, I hope).
If the long format frame was corrupted while on the user stack, the
partially completed MOVEM won't be resumed correctly. That's why I was
concerned about a bug in sys_sigreturn.
Our problem may be that, if we take the signal too late and our main
process inspects the stack that has been left partially saved only (due
to the bus error processing still in-flight), we appear to be in
trouble. After completing sys_sigreturn, everything will be OK.
I can see this cause the stack error in the test case. Not sure it also
applies to the dash case ...
Wouldn't that depend on the exception frame format? Perhaps it is
unsafe to treat any format 0xB exception frame in the way we do. If
so, what do we do about address error exceptions, which are to produce
SIGBUS? The Programmers Reference Manual says "a long bus fault stack
frame may be generated" in this case.
We don't handle access errors (beyond terminating the offending
process).
SIGBUS could be caught and handled, perhaps followed by a setcontext() or
siglongjmp() rather than return. So I don't think we get to disallow frame
format 0xB.
