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.
