[PATCH v2 09/12] ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds

Ard Biesheuvel ardb at kernel.org
Tue Feb 1 06:05:25 PST 2022


On Tue, 1 Feb 2022 at 14:18, Masami Hiramatsu <mhiramat at kernel.org> wrote:
>
> On Mon, 31 Jan 2022 18:03:44 +0100
> Ard Biesheuvel <ardb at kernel.org> wrote:
>
> > Thumb2 code uses R7 as the frame pointer rather than R11, because the
> > opcodes to access it are generally shorter.
> >
> > This means that there are cases where we cannot simply add it to the
> > clobber list of an asm() block, but need to preserve/restore it
> > explicitly, or the compiler may complain in some cases (e.g., Clang
> > builds with ftrace enabled).
> >
> > Since R11 is not special in that case, clobber it instead, and use it to
> > preserve/restore the value of R7.
>
> Thanks Ard for fixing thumb2 issue!

No problem. Although I'm still not 100% sure we can simply
preserve/restore the frame pointer like that. What is the expected
result when an exception occurs in the kprobes emulation code?

The main problem is that with unwind info unwinding, the stack pointer
and the frame pointer need to be mutually in sync, and with the
kprobes stack frames in the middle, this is no longer correct - the
emulated code is executed with the frame pointer value that was
captured when the probe was hit, by the stack has a couple of frames
added.

> BTW, have you build the kernel with CONFIG_KPROBES_SANITY_TEST=y?
> It should check the backtrace from kprobe and kretprobe at boot time.
>

Just checked, and those work fine.



More information about the linux-arm-kernel mailing list