Re: signal delivery, was Re: reliable reproducer

[Finn Thain <fthain@linux-m68k.org>]

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.