Re: [PATCH RFC v1] m68k: signal.c: use signal frame gap to avoid stack corruption

[Michael Schmitz <schmitzmic@gmail.com>]

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