[PATCH 1/2] powerpc/jprobes: Save and restore the parameter save area

[Naveen N. Rao]

On 2017/05/18 03:22PM, Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao at linux.vnet.ibm.com> writes:
> 
> > As pointed out in x86 setjmp_pre_handler(), we need to save and restore
> > the parameter save area since the jprobe hook might overwrite it. Since
> > there is no easy way to identify the size of the parameter save area,
> > we choose to save/restore a fixed 16 [double]word-sized area including
> > the stack frame header.
> >
> > We introduce STACK_FRAME_PARM_SAVE to encode the offset of the parameter
> > save area from the stack frame pointer. Remove the similarly named
> > PARAMETER_SAVE_AREA_OFFSET in ptrace.c as those are currently not used
> > anywhere.
> >
> > Signed-off-by: Naveen N. Rao <naveen.n.rao at linux.vnet.ibm.com>
> > ---
> > Michael,
> > I've set the limit to 16 parameters as being a "reasonable" number, but
> > we could very well make this 24 or 32 if we want to be sure. Let me
> > know what you prefer.
> 
> That sounds incredibly fragile. Are we really just guessing at the size
> required? What happens if we under estimate, do we crash, silently
> corrupt data .. ?

There is a _chance_ of crashing/corrupting data, yes. The conditions 
required for that include:
- a function that takes > 8 parameters, hence requiring parameters to be 
  passed on the stack
- the jprobe hook replacing that function having to clobber one of those 
  parameters passed on the stack.

Assuming C code, I am not sure what conditions could trigger gcc to emit 
code that may do the latter. However, per the ABI, this is possible as 
the parameter save area is owned by the callee and the caller can't 
assume that it'll remain intact.

Given the slim probability, I felt that saving/restoring a fixed amount 
of stack is sufficient to mitigate this. The other option is to 
save/restore the entire stack frame, but that may be quite large and 
just a lot of overhead in most cases.

Thoughts?

- Naveen