On Wed, 9 Oct 2024 18:13:54 +0200
Ard Biesheuvel <[email protected]> wrote:
> > > @@ -256,7 +254,6 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL)
> > > movq R14(%rsp), %r14
> > > movq R13(%rsp), %r13
> > > movq R12(%rsp), %r12
> > > - movq R10(%rsp), %r10
> >
> > This part of the patch I think is perfectly fine. We haven't been restoring
> > R11 for 12 years I'm sure nobody will notice if we don't restore R10.
> >
>
> Not sure I follow this reasoning tbh. R10/R11 are guaranteed to be
> dead, so I don't see any point in preserving them. But if you do
> capture them, shouldn't you at least ensure that the captured values
> match the values that the callee will observe? (even though they are
> dead and we know it will never look at them)
Say we have code of:
pushq r10
pushq r11
call foo
popq r11
popq r10
Where we add a kprobe to the start of foo, the callback should be able to
see what r10 and r11 were. But the restore part is for the function foo to
see. It shouldn't care about r10 or r11 and if a kprobe updates them, it
should not have any effect.
What does restoring r10 and r11 give us?
-- Steve
