Re: reliable reproducer, was Re: core dump analysis

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Andreas,

On 23/04/23 20:23, Andreas Schwab wrote:
> On Apr 23 2023, Michael Schmitz wrote:
>
>> Wasn't too hard actually. The signo parameter passed to the handler turns
>> out to be passed by reference, and signo is located 4 bytes into the
>> kernel sigframe.
> That's not "passed by reference".  Function arguments are always passed
> on the stack.

You're right of course, I should have phrased that different.

signo is passed by value as the first argument on the stack, but I can 
take a reference to signo to find it's address on the stack. That in 
turn will tell me the address of the complete signal frame on the stack.

This works because at the time the handler is entered, the stack points 
to the return address which has been set up by setup_frame, and that's 
the first longword in struct sigframe (frame.pretcode; points to 
frame.retcode which holds the trampoline code that will call 
sys_sigreturn upon exit from the handler). This in turn works because 
usp is loaded with the address of the sigframe right before calling the 
handler.

In effect, at least indirectly the signal handler receives all two 
arguments that matter (signo and sigcontext) even though sigcontext is 
not explicitly passed on the stack (the third longword is frame.code 
which holds the vector number AFAICS). Not sure what third argument you 
referred to in another mail.

With the rt_sigframe, pointers to siginfo and ucontext are stored after 
signo so no stack arithmetics is needed there to access all three 
arguments.

Anyway, the whole point of the exercise was to see whether I can peek at 
the registers in the signal frame and their saved copies on the stack, 
to perhaps spot when the stack corruption begins to happen. I know - 
should have used a debugger in the first place instead instrumenting a 
test case.

Cheers,

     Michael