Hi Andreas,
Am 29.04.2023 um 20:17 schrieb Andreas Schwab:
On Apr 29 2023, Michael Schmitz wrote:
We can use the format b fault address in frame.un.fmtb.daddr
to find the address where the fault occurred, i.e. the
address where the instruction will resume.
I don't think you can assume any order of transfer.
True - I've been seeing this too much through the lens of this
particular bug - moveml to user stack faulting while crossing a page
boundary.
The more typical case appears to look like this:
[ 4703.880000] get_sigframe: signal stack 0xeffff758 fault daddr 0x8003f328
[ 5009.830000] get_sigframe: signal stack 0xefffef80 fault daddr 0x80029c88
[ 6152.750000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x8006a290
[ 6985.290000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x8006a290
[ 7260.060000] get_sigframe: signal stack 0xeffff020 fault daddr 0x80050cec
[ 7794.080000] get_sigframe: signal stack 0xc0001ea0 fault daddr 0x8000c69c
[ 7797.240000] get_sigframe: signal stack 0xeffff08c fault daddr 0xc00f4f7e
[ 7942.460000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x80050cec
[ 9833.180000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x80050cec
[10153.500000] get_sigframe: signal stack 0xeffff020 fault daddr 0x8006a290
[10781.110000] get_sigframe: signal stack 0xeffff3c8 fault daddr 0x800435dc
[11648.290000] get_sigframe: signal stack 0xeffff8f0 fault daddr 0x800024f0
[11773.260000] get_sigframe: signal stack 0xeffff3d0 fault daddr 0x8002f858
[12117.380000] get_sigframe: signal stack 0xeffffa08 fault daddr 0x8006a290
[12526.350000] get_sigframe: signal stack 0xefffef78 fault daddr 0xc006fba0
[12875.800000] get_sigframe: signal stack 0xc043de08 fault daddr 0x800b5f68
[15682.160000] get_sigframe: signal stack 0xeffff8f0 fault daddr 0xc00c37c8
[16503.110000] get_sigframe: signal stack 0xeffff730 fault daddr 0x80050cec
[16545.560000] get_sigframe: signal stack 0xeffff6ac fault daddr 0x80050cec
Fault address and USP are entirely unrelated (and no risk of overwriting
the area where the fault occurred).
My (rather convoluted) checks that are meant to ensure fault address and
stack pointer are on immediately adjacent pages, and not miles apart
should take care of these above cases.
But I had indeed overlooked the case of crossing a page boundary
upwards. Thanks for pointing that out.
As it turns out, in this case using the area on the user stack
immediately below USP won't hurt - the transfer direction is away from
the end of the signal frame, and as long as the signal stack remains
below USP, it does not overwrite anything already on the stack that a
resume would miss. No need to shift the signal frame out of the way.
What else am I missing? Examination of the stack contents from the
signal handler before resuming the movem through rte has shown the order
and direction of transfer is as expect for @sp-, i.e. downwards...
Cheers,
Michael
