Re: signal delivery, was Re: reliable reproducer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux