Hi Finn,
Am 26.04.2023 um 16:42 schrieb Finn Thain:
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.
Yes, it turns out I hadn't read mangle_kernel_stack() carefully enough.
I thought the exception frame had remained on the kernel stack to be
restored, but I'd missed that it is actually being restored from the
user stack copy to the kernel stack.
Need to go back and check whether the sigmask (located after uc_filler
in rt sigframes) ever got clobbered.
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
Meant to say 'address errors' there. These are misaligned instruction
accesses only, and we take them to indicate corruption of the binary or
stack, so abort the process.
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.
Yes, we may still need to take these signals. But we don't have to
deliver the signals to the user process while exception processing is
still in progress. For bus faults mid-instruction, it isn't enough to
map in a page so writes can succeed, we also need to resume the
instruction to carry out the write.
Come to think of it, the same argument applies for faults taken at an
instruction boundary. These need to be resumed as well, they just take
less information to load back into the processor.
Now I just wonder why 040 bus errors (exception restart instead of
resume) aren't a problem. Pending writebacks are handled during signal
return there, too. But the format 7 frame is only 15 longwords, the
format b one is 23 longwords. We know increasing the apparent length of
the signal frame helps ...
Anyway, Andreas' patch addresses the issue without incurring too much
delay in signal processing. If we find out what causes corruption of the
exception frame, Andreas' patch can be dropped once a fix is in place.
Cheers,
Michael
