* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: "David A. Long" <dave.long@linaro.org>
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first seen in October 2013. This version attempts to address concerns
raised by reviewers and also fixes problems discovered during testing.
This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
and return probes(kretprobes) support for ARM64.
The kprobes mechanism makes use of software breakpoint and single stepping
support available in the ARM v8 kernel.
Changes since v2 include:
1) Removal of NOP padding in kprobe XOL slots. Slots are now exactly one
instruction long.
2) Disabling of interrupts during execution in single-step mode.
3) Fixing of numerous problems in instruction simulation code (mostly
thanks to Will Cohen).
4) Support for the HAVE_REGS_AND_STACK_ACCESS_API feature is added, to
allow access to kprobes through debugfs.
5) kprobes is *not* enabled in defconfig.
6) Numerous complaints from checkpatch have been cleaned up, although a
couple remain as removing the function pointer typedefs results in ugly
code.
Changes since v3 include:
1) Remove table-driven instruction parsing and replace with an if statement
calling out to old and new instruction test functions in insn.c.
2) I removed the addition of orig_x0 to ptrace.h.
3) Reorder the patches.
4) Replace the previous interrupt disabling (from Will Cohen) with
an improved solution (from Steve Capper).
Changes since v4 include:
1) Added insn.c functions to detect exception instructions and DAIF
read/write instructions, and use them to reject probing same.
2) Changed adr detect function to also recognize adrp. Reject both.
3) Added missing __kprobes for some new functions.
4) Added call to kprobes_fault_handler from mm do_page_fault.
5) Reject all non-simulated branch/ret instructions, not just those
that use an immediate offset.
6) Moved software breakpoint definitions into debug-monitors.h.
7) Removed "!XIP_KERNEL" from Kconfig.
8) changed kprobes_condition_check_t and kprobes_prepare_t to probes_*,
for future sharing with uprobes.
9) Removed bogus call to kprobes_restore_local_irqflag() from
trampoline_probe_handler().
Changes since v5 include:
1) Replaced installation of breakpoint hook with direct call from the
handlers in debug-monitors.c, as requested.
2) Reject probing of instructions that read the interrupt mask, in
addition to instructions that set it.
3) Cleaned up comments describing usage of Debug Mask.
4) Added KPROBE_REENTER case in reenter_kprobe.
5) Corrected the ifdef'd definitions for notify_page_fault() to be
consistent when KPROBES is not configed.
6) Changed "cpsr" to "pstate" for HAVE_REGS_AND_STACK_ACCESS_API feature.
7) Added back in missing new files in previous patch.
8) Changed two instances of pr_warning() to pr_warn().
Note that there seems to be at least a potential issue with kprobes
on multiple (possibly all) platforms having to do with use of kfree
inside of the kretprobes trampoline handler. This has manifested
occasionally in systemtap testing on arm64. There does not appear to
be an simple solution to the problem.
Changes since v6 include:
1) New trampoline code from Will Cohen fixes the occasional failure seen
when processing kretprobes by replacing the software breakpoint with
assembly code to implement the return to the original execution stream.
2) Changed ip0, ip1, fp, and lr to plain numbered registers for purposes
of recognizing them as an ascii string in the stack/reg access code.
3) Removed orig_x0.
4) Moved ARM_x* defines from arch/arm64/include/uapi/asm/ptrace.h to
arch/arm64/kernel/ptrace.c.
Changes since v7 include:
1) Move trampoline entry/return code into separate ".S" file instead
of making it a macro in a header file.
2) Add missing register name definitions in asm-offsets.c and use them
in place of hard-coded integer offsets in the trampoline code.
3) Correct the values used to decode MSR immediate instructions, in insn.h.
4) Remove the currently unused simulate_none() function.
Changes since v8 include:
1) Replaced use of REG_OFFSET_NAME with GPR_OFFSET_NAME for numbered
registers.
2) Added an alias for "lr" in the register name lookup table, which perf
tools need to be able to recognize.
3) Changed the code for checking instruction types for probeability and
steppability as per review feedback.
4) Fixed the size of cache being flushed when filling single-step slot.
5) Fixed big-endian issues.
6) Blacklisted copy_to/from_user to avoid aborts while single-stepping.
7) Record conditional instructions that fail the conditional test just
like any other probed (non-conditional) instruction.
8) Removed use of magic number for detecting jprobe return and just
check the breakpoint address instead.
9) Got rid of the unnecessary arch/arm64/kprobes.h.
10) The PSTATE and SP are now properly saved in the kretprobe trampoline
code.
11) This patch no longer depends on the "Consolidate redundant
register/stack access code" patch set.
12) Remove call to fixup_exception from kprobe_fault_handler.
Changes since v9 include:
1) Remove arch/arm/opcodes.c from the arm64 build and move the renamed
arm64_check_condition() function to armv8_deprecated.c. Remove the
asmlinkage.
2) Various other type and style changes suggested by Marc Zyngier.
3) Put back the call to fixup_exception from kprobe_fault_handler.
It proved to be necessary for correct operation.
Changes since v10 include:
1) Rename arm64_check_condition() to arm32_check_condition().
2) Remove redundant define of ARM_OPCODE_CONDITION_UNCOND.
3) Use a accessor functions to read and write registers by number
in the simulation code, to avoid accidentally overriding parts of
the pt_regs structure (e.g.: when the reg is xzr).
4) Remove unused register offset defines.
5) Replace instance of "(void *) 0" with NULL.
6) Rewrite the kretprobe trampoline code using arch/arm64/kvm/hyp/entry.S
as an example. Construct a more complete saved PSTATE in this code.
Changes since v11 include:
1) Add check for address within irq stack, in regs_within_kernel_stack()
2) Replaced inappropriate use of user_pt_regs with pt_regs.
3) Added comments to opcode_condition_checks table explaining equivalence
of "nv" and "al" condition codes.
4) Cleaned up some subtle problems in the instruction simulation code.
5) Readability improvements in kprobes_trampoline.S.
6) Additional blacklisting for entry code, exception handling code, and
select debug functions.
7) Check address to be probed for proper alignment.
8) Add rodata section to areas where kprobes may not be placed.
Changes since v12 include:
1) Changed regs_get_register() to expicitly reference pt_regs structure
fields instead of just using an address offset.
2) Reject probing of eret.
3) Correctly handle addresses on the interrupt stack
4) Add kprobe_ctlblk argument to static irqflag handling functions to avoid
doing extra calls to get_kprobe_ctlblk().
5) Removed a couple of logically redundant assignments to kprobe_status.
6) Added calls to pause_graph_tracing/unpause_graph_tracing to avoid
disaster when kprobe'ing and tracing at the same time.
7) Added idmap and hypervisor text sections to blacklisted regions
8) Numerous additional comments, formatting changes, and rearranging
of if-else statements.
Changes since v13 include:
1) Fixed regs_get_register() from previous version to correctly calculate
the offset of registers in struct pt_regs.
2) I removed the removal of the typecast inside the instruction_pointer()
define in ptrace.h, and added a define for instruction_pointer_set(). This
was necessary to correct warnings that were being emitted when compiling
kgdb code.
3) Removed a redundant/bogus "NOKPROBE_SYMBOL(do_debug_exception)"
statement.
4) Fixed aarch64_insn_extract_system_reg() from previous version to use the
correct name "aarch64_insn_extract_system_reg()".
5) Changed opcode_condition_checks[] to aarch32_opcode_cond_checks[] and
arm32_check_condition() to aarch32_check_condition().
6) I switched the order of the main kprobes patch and the symbol function
blacklisting patch back to the order they were done in the earlier patches.
7) I got rid of struct kprobe_pc_restore and now just use a non-zero saved
PC as the flag to restore the PC.
8) I changed the names of some of the arm64 kprobes source files and moved
then into their own "kprobes" subdirectory under arch/arm64/kernel.
9) I moved the INSN_GOOD_NO_SLOT enum value to the later commit that makes
use of it.
10) I added kernel_disable_single_stap() and spsr_set_debug_flag() calls in
kprobe_fault_handler() for the KPROBE_REENTER case.
11) I brought trampoline_probe_handler() up to date with x86 sources to
pick up a fix from Syuhei (commit 737480a0d525).
12) I changed samples/kprobes/kprobe_example.c modifications to more
closely match what is currently done for other architectures.
Changes since v14:
1) Change the name of arch/arm64/kernel/kprobes to
arch/arm64/kernel/probes/ and fix the name in the Makefile and comments.
2) Include include/linux/asm-generic/ptrace.h in
arch/arm64/include/asm/ptrace.h, add the required definitions in the latter
to make this work, and add a couple typecasts in
arch/arm64/kernel/probes/kprobes.c to accomodate this.
3) added Ack's to commits.
David A. Long (3):
arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
arm64: Add more test functions to insn.c
arm64: add conditional instruction simulation support
Pratyush Anand (2):
arm64: Blacklist non-kprobe-able symbol
arm64: Treat all entry code as non-kprobe-able
Sandeepa Prabhu (4):
arm64: Kprobes with single stepping support
arm64: kprobes instruction simulation support
arm64: Add kernel return probes support (kretprobes)
kprobes: Add arm64 case in kprobe example module
William Cohen (1):
arm64: Add trampoline code for kretprobes
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/debug-monitors.h | 5 +
arch/arm64/include/asm/insn.h | 41 ++
arch/arm64/include/asm/kprobes.h | 62 +++
arch/arm64/include/asm/probes.h | 35 ++
arch/arm64/include/asm/ptrace.h | 66 ++-
arch/arm64/kernel/Makefile | 5 +-
arch/arm64/kernel/arm64ksyms.c | 2 +
arch/arm64/kernel/armv8_deprecated.c | 19 +-
arch/arm64/kernel/asm-offsets.c | 11 +
arch/arm64/kernel/debug-monitors.c | 33 +-
arch/arm64/kernel/entry.S | 3 +
arch/arm64/kernel/hw_breakpoint.c | 8 +
arch/arm64/kernel/insn.c | 133 +++++
arch/arm64/kernel/kgdb.c | 4 +
arch/arm64/kernel/probes/Makefile | 3 +
arch/arm64/kernel/probes/decode-insn.c | 174 +++++++
arch/arm64/kernel/probes/decode-insn.h | 35 ++
arch/arm64/kernel/probes/kprobes.c | 675 ++++++++++++++++++++++++++
arch/arm64/kernel/probes/kprobes_trampoline.S | 85 ++++
arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++
arch/arm64/kernel/probes/simulate-insn.h | 28 ++
arch/arm64/kernel/ptrace.c | 118 +++++
arch/arm64/kernel/vmlinux.lds.S | 2 +
arch/arm64/mm/fault.c | 26 +
samples/kprobes/kprobe_example.c | 9 +
26 files changed, 1794 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/include/asm/kprobes.h
create mode 100644 arch/arm64/include/asm/probes.h
create mode 100644 arch/arm64/kernel/probes/Makefile
create mode 100644 arch/arm64/kernel/probes/decode-insn.c
create mode 100644 arch/arm64/kernel/probes/decode-insn.h
create mode 100644 arch/arm64/kernel/probes/kprobes.c
create mode 100644 arch/arm64/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
--
2.5.0
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first seen in October 2013. This version attempts to address concerns
raised by reviewers and also fixes problems discovered during testing.
This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
and return probes(kretprobes) support for ARM64.
The kprobes mechanism makes use of software breakpoint and single stepping
support available in the ARM v8 kernel.
Changes since v2 include:
1) Removal of NOP padding in kprobe XOL slots. Slots are now exactly one
instruction long.
2) Disabling of interrupts during execution in single-step mode.
3) Fixing of numerous problems in instruction simulation code (mostly
thanks to Will Cohen).
4) Support for the HAVE_REGS_AND_STACK_ACCESS_API feature is added, to
allow access to kprobes through debugfs.
5) kprobes is *not* enabled in defconfig.
6) Numerous complaints from checkpatch have been cleaned up, although a
couple remain as removing the function pointer typedefs results in ugly
code.
Changes since v3 include:
1) Remove table-driven instruction parsing and replace with an if statement
calling out to old and new instruction test functions in insn.c.
2) I removed the addition of orig_x0 to ptrace.h.
3) Reorder the patches.
4) Replace the previous interrupt disabling (from Will Cohen) with
an improved solution (from Steve Capper).
Changes since v4 include:
1) Added insn.c functions to detect exception instructions and DAIF
read/write instructions, and use them to reject probing same.
2) Changed adr detect function to also recognize adrp. Reject both.
3) Added missing __kprobes for some new functions.
4) Added call to kprobes_fault_handler from mm do_page_fault.
5) Reject all non-simulated branch/ret instructions, not just those
that use an immediate offset.
6) Moved software breakpoint definitions into debug-monitors.h.
7) Removed "!XIP_KERNEL" from Kconfig.
8) changed kprobes_condition_check_t and kprobes_prepare_t to probes_*,
for future sharing with uprobes.
9) Removed bogus call to kprobes_restore_local_irqflag() from
trampoline_probe_handler().
Changes since v5 include:
1) Replaced installation of breakpoint hook with direct call from the
handlers in debug-monitors.c, as requested.
2) Reject probing of instructions that read the interrupt mask, in
addition to instructions that set it.
3) Cleaned up comments describing usage of Debug Mask.
4) Added KPROBE_REENTER case in reenter_kprobe.
5) Corrected the ifdef'd definitions for notify_page_fault() to be
consistent when KPROBES is not configed.
6) Changed "cpsr" to "pstate" for HAVE_REGS_AND_STACK_ACCESS_API feature.
7) Added back in missing new files in previous patch.
8) Changed two instances of pr_warning() to pr_warn().
Note that there seems to be at least a potential issue with kprobes
on multiple (possibly all) platforms having to do with use of kfree
inside of the kretprobes trampoline handler. This has manifested
occasionally in systemtap testing on arm64. There does not appear to
be an simple solution to the problem.
Changes since v6 include:
1) New trampoline code from Will Cohen fixes the occasional failure seen
when processing kretprobes by replacing the software breakpoint with
assembly code to implement the return to the original execution stream.
2) Changed ip0, ip1, fp, and lr to plain numbered registers for purposes
of recognizing them as an ascii string in the stack/reg access code.
3) Removed orig_x0.
4) Moved ARM_x* defines from arch/arm64/include/uapi/asm/ptrace.h to
arch/arm64/kernel/ptrace.c.
Changes since v7 include:
1) Move trampoline entry/return code into separate ".S" file instead
of making it a macro in a header file.
2) Add missing register name definitions in asm-offsets.c and use them
in place of hard-coded integer offsets in the trampoline code.
3) Correct the values used to decode MSR immediate instructions, in insn.h.
4) Remove the currently unused simulate_none() function.
Changes since v8 include:
1) Replaced use of REG_OFFSET_NAME with GPR_OFFSET_NAME for numbered
registers.
2) Added an alias for "lr" in the register name lookup table, which perf
tools need to be able to recognize.
3) Changed the code for checking instruction types for probeability and
steppability as per review feedback.
4) Fixed the size of cache being flushed when filling single-step slot.
5) Fixed big-endian issues.
6) Blacklisted copy_to/from_user to avoid aborts while single-stepping.
7) Record conditional instructions that fail the conditional test just
like any other probed (non-conditional) instruction.
8) Removed use of magic number for detecting jprobe return and just
check the breakpoint address instead.
9) Got rid of the unnecessary arch/arm64/kprobes.h.
10) The PSTATE and SP are now properly saved in the kretprobe trampoline
code.
11) This patch no longer depends on the "Consolidate redundant
register/stack access code" patch set.
12) Remove call to fixup_exception from kprobe_fault_handler.
Changes since v9 include:
1) Remove arch/arm/opcodes.c from the arm64 build and move the renamed
arm64_check_condition() function to armv8_deprecated.c. Remove the
asmlinkage.
2) Various other type and style changes suggested by Marc Zyngier.
3) Put back the call to fixup_exception from kprobe_fault_handler.
It proved to be necessary for correct operation.
Changes since v10 include:
1) Rename arm64_check_condition() to arm32_check_condition().
2) Remove redundant define of ARM_OPCODE_CONDITION_UNCOND.
3) Use a accessor functions to read and write registers by number
in the simulation code, to avoid accidentally overriding parts of
the pt_regs structure (e.g.: when the reg is xzr).
4) Remove unused register offset defines.
5) Replace instance of "(void *) 0" with NULL.
6) Rewrite the kretprobe trampoline code using arch/arm64/kvm/hyp/entry.S
as an example. Construct a more complete saved PSTATE in this code.
Changes since v11 include:
1) Add check for address within irq stack, in regs_within_kernel_stack()
2) Replaced inappropriate use of user_pt_regs with pt_regs.
3) Added comments to opcode_condition_checks table explaining equivalence
of "nv" and "al" condition codes.
4) Cleaned up some subtle problems in the instruction simulation code.
5) Readability improvements in kprobes_trampoline.S.
6) Additional blacklisting for entry code, exception handling code, and
select debug functions.
7) Check address to be probed for proper alignment.
8) Add rodata section to areas where kprobes may not be placed.
Changes since v12 include:
1) Changed regs_get_register() to expicitly reference pt_regs structure
fields instead of just using an address offset.
2) Reject probing of eret.
3) Correctly handle addresses on the interrupt stack
4) Add kprobe_ctlblk argument to static irqflag handling functions to avoid
doing extra calls to get_kprobe_ctlblk().
5) Removed a couple of logically redundant assignments to kprobe_status.
6) Added calls to pause_graph_tracing/unpause_graph_tracing to avoid
disaster when kprobe'ing and tracing at the same time.
7) Added idmap and hypervisor text sections to blacklisted regions
8) Numerous additional comments, formatting changes, and rearranging
of if-else statements.
Changes since v13 include:
1) Fixed regs_get_register() from previous version to correctly calculate
the offset of registers in struct pt_regs.
2) I removed the removal of the typecast inside the instruction_pointer()
define in ptrace.h, and added a define for instruction_pointer_set(). This
was necessary to correct warnings that were being emitted when compiling
kgdb code.
3) Removed a redundant/bogus "NOKPROBE_SYMBOL(do_debug_exception)"
statement.
4) Fixed aarch64_insn_extract_system_reg() from previous version to use the
correct name "aarch64_insn_extract_system_reg()".
5) Changed opcode_condition_checks[] to aarch32_opcode_cond_checks[] and
arm32_check_condition() to aarch32_check_condition().
6) I switched the order of the main kprobes patch and the symbol function
blacklisting patch back to the order they were done in the earlier patches.
7) I got rid of struct kprobe_pc_restore and now just use a non-zero saved
PC as the flag to restore the PC.
8) I changed the names of some of the arm64 kprobes source files and moved
then into their own "kprobes" subdirectory under arch/arm64/kernel.
9) I moved the INSN_GOOD_NO_SLOT enum value to the later commit that makes
use of it.
10) I added kernel_disable_single_stap() and spsr_set_debug_flag() calls in
kprobe_fault_handler() for the KPROBE_REENTER case.
11) I brought trampoline_probe_handler() up to date with x86 sources to
pick up a fix from Syuhei (commit 737480a0d525).
12) I changed samples/kprobes/kprobe_example.c modifications to more
closely match what is currently done for other architectures.
Changes since v14:
1) Change the name of arch/arm64/kernel/kprobes to
arch/arm64/kernel/probes/ and fix the name in the Makefile and comments.
2) Include include/linux/asm-generic/ptrace.h in
arch/arm64/include/asm/ptrace.h, add the required definitions in the latter
to make this work, and add a couple typecasts in
arch/arm64/kernel/probes/kprobes.c to accomodate this.
3) added Ack's to commits.
David A. Long (3):
arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
arm64: Add more test functions to insn.c
arm64: add conditional instruction simulation support
Pratyush Anand (2):
arm64: Blacklist non-kprobe-able symbol
arm64: Treat all entry code as non-kprobe-able
Sandeepa Prabhu (4):
arm64: Kprobes with single stepping support
arm64: kprobes instruction simulation support
arm64: Add kernel return probes support (kretprobes)
kprobes: Add arm64 case in kprobe example module
William Cohen (1):
arm64: Add trampoline code for kretprobes
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/debug-monitors.h | 5 +
arch/arm64/include/asm/insn.h | 41 ++
arch/arm64/include/asm/kprobes.h | 62 +++
arch/arm64/include/asm/probes.h | 35 ++
arch/arm64/include/asm/ptrace.h | 66 ++-
arch/arm64/kernel/Makefile | 5 +-
arch/arm64/kernel/arm64ksyms.c | 2 +
arch/arm64/kernel/armv8_deprecated.c | 19 +-
arch/arm64/kernel/asm-offsets.c | 11 +
arch/arm64/kernel/debug-monitors.c | 33 +-
arch/arm64/kernel/entry.S | 3 +
arch/arm64/kernel/hw_breakpoint.c | 8 +
arch/arm64/kernel/insn.c | 133 +++++
arch/arm64/kernel/kgdb.c | 4 +
arch/arm64/kernel/probes/Makefile | 3 +
arch/arm64/kernel/probes/decode-insn.c | 174 +++++++
arch/arm64/kernel/probes/decode-insn.h | 35 ++
arch/arm64/kernel/probes/kprobes.c | 675 ++++++++++++++++++++++++++
arch/arm64/kernel/probes/kprobes_trampoline.S | 85 ++++
arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++
arch/arm64/kernel/probes/simulate-insn.h | 28 ++
arch/arm64/kernel/ptrace.c | 118 +++++
arch/arm64/kernel/vmlinux.lds.S | 2 +
arch/arm64/mm/fault.c | 26 +
samples/kprobes/kprobe_example.c | 9 +
26 files changed, 1794 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/include/asm/kprobes.h
create mode 100644 arch/arm64/include/asm/probes.h
create mode 100644 arch/arm64/kernel/probes/Makefile
create mode 100644 arch/arm64/kernel/probes/decode-insn.c
create mode 100644 arch/arm64/kernel/probes/decode-insn.h
create mode 100644 arch/arm64/kernel/probes/kprobes.c
create mode 100644 arch/arm64/kernel/probes/kprobes_trampoline.S
create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
--
2.5.0
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: "David A. Long" <dave.long@linaro.org>
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64, including supporting
functions and defines.
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.h | 52 ++++++++++++++++++
arch/arm64/kernel/ptrace.c | 118 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 171 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691..fab133c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -85,6 +85,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index a307eb6..6c0c7d3 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -74,6 +74,7 @@
#define COMPAT_PT_DATA_ADDR 0x10004
#define COMPAT_PT_TEXT_END_ADDR 0x10008
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
/* sizeof(struct user) for AArch32 */
#define COMPAT_USER_SZ 296
@@ -119,6 +120,8 @@ struct pt_regs {
u64 syscallno;
};
+#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
+
#define arch_has_single_step() (1)
#ifdef CONFIG_COMPAT
@@ -147,6 +150,55 @@ struct pt_regs {
#define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset: offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ u64 val = 0;
+
+ WARN_ON(offset & 7);
+
+ offset >>= 3;
+ switch (offset) {
+ case 0 ... 30:
+ val = regs->regs[offset];
+ break;
+ case offsetof(struct pt_regs, sp) >> 3:
+ val = regs->sp;
+ break;
+ case offsetof(struct pt_regs, pc) >> 3:
+ val = regs->pc;
+ break;
+ case offsetof(struct pt_regs, pstate) >> 3:
+ val = regs->pstate;
+ break;
+ default:
+ val = 0;
+ }
+
+ return val;
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
static inline unsigned long regs_return_value(struct pt_regs *regs)
{
return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 3f6cd5c..2c88c33 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,124 @@
#define CREATE_TRACE_POINTS
#include <trace/events/syscalls.h>
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#define GPR_OFFSET_NAME(r) \
+ {.name = "x" #r, .offset = offsetof(struct pt_regs, regs[r])}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ GPR_OFFSET_NAME(0),
+ GPR_OFFSET_NAME(1),
+ GPR_OFFSET_NAME(2),
+ GPR_OFFSET_NAME(3),
+ GPR_OFFSET_NAME(4),
+ GPR_OFFSET_NAME(5),
+ GPR_OFFSET_NAME(6),
+ GPR_OFFSET_NAME(7),
+ GPR_OFFSET_NAME(8),
+ GPR_OFFSET_NAME(9),
+ GPR_OFFSET_NAME(10),
+ GPR_OFFSET_NAME(11),
+ GPR_OFFSET_NAME(12),
+ GPR_OFFSET_NAME(13),
+ GPR_OFFSET_NAME(14),
+ GPR_OFFSET_NAME(15),
+ GPR_OFFSET_NAME(16),
+ GPR_OFFSET_NAME(17),
+ GPR_OFFSET_NAME(18),
+ GPR_OFFSET_NAME(19),
+ GPR_OFFSET_NAME(20),
+ GPR_OFFSET_NAME(21),
+ GPR_OFFSET_NAME(22),
+ GPR_OFFSET_NAME(23),
+ GPR_OFFSET_NAME(24),
+ GPR_OFFSET_NAME(25),
+ GPR_OFFSET_NAME(26),
+ GPR_OFFSET_NAME(27),
+ GPR_OFFSET_NAME(28),
+ GPR_OFFSET_NAME(29),
+ GPR_OFFSET_NAME(30),
+ {.name = "lr", .offset = offsetof(struct pt_regs, regs[30])},
+ REG_OFFSET_NAME(sp),
+ REG_OFFSET_NAME(pc),
+ REG_OFFSET_NAME(pstate),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (!strcmp(roff->name, name))
+ return roff->offset;
+ return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its offset
+ * @offset: the offset of a register in struct pt_regs.
+ *
+ * regs_query_register_name() returns the name of a register from its
+ * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
+ */
+const char *regs_query_register_name(unsigned int offset)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (roff->offset == offset)
+ return roff->name;
+ return NULL;
+}
+
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @addr: address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
+{
+ return ((addr & ~(THREAD_SIZE - 1)) ==
+ (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1))) ||
+ on_irq_stack(addr, raw_smp_processor_id());
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */
+unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
+{
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+ addr += n;
+ if (regs_within_kernel_stack(regs, (unsigned long)addr))
+ return *addr;
+ else
+ return 0;
+}
+
/*
* TODO: does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64, including supporting
functions and defines.
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.h | 52 ++++++++++++++++++
arch/arm64/kernel/ptrace.c | 118 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 171 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5a0a691..fab133c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -85,6 +85,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index a307eb6..6c0c7d3 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -74,6 +74,7 @@
#define COMPAT_PT_DATA_ADDR 0x10004
#define COMPAT_PT_TEXT_END_ADDR 0x10008
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
/* sizeof(struct user) for AArch32 */
#define COMPAT_USER_SZ 296
@@ -119,6 +120,8 @@ struct pt_regs {
u64 syscallno;
};
+#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
+
#define arch_has_single_step() (1)
#ifdef CONFIG_COMPAT
@@ -147,6 +150,55 @@ struct pt_regs {
#define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset: offset of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ u64 val = 0;
+
+ WARN_ON(offset & 7);
+
+ offset >>= 3;
+ switch (offset) {
+ case 0 ... 30:
+ val = regs->regs[offset];
+ break;
+ case offsetof(struct pt_regs, sp) >> 3:
+ val = regs->sp;
+ break;
+ case offsetof(struct pt_regs, pc) >> 3:
+ val = regs->pc;
+ break;
+ case offsetof(struct pt_regs, pstate) >> 3:
+ val = regs->pstate;
+ break;
+ default:
+ val = 0;
+ }
+
+ return val;
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
static inline unsigned long regs_return_value(struct pt_regs *regs)
{
return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 3f6cd5c..2c88c33 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,124 @@
#define CREATE_TRACE_POINTS
#include <trace/events/syscalls.h>
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#define GPR_OFFSET_NAME(r) \
+ {.name = "x" #r, .offset = offsetof(struct pt_regs, regs[r])}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ GPR_OFFSET_NAME(0),
+ GPR_OFFSET_NAME(1),
+ GPR_OFFSET_NAME(2),
+ GPR_OFFSET_NAME(3),
+ GPR_OFFSET_NAME(4),
+ GPR_OFFSET_NAME(5),
+ GPR_OFFSET_NAME(6),
+ GPR_OFFSET_NAME(7),
+ GPR_OFFSET_NAME(8),
+ GPR_OFFSET_NAME(9),
+ GPR_OFFSET_NAME(10),
+ GPR_OFFSET_NAME(11),
+ GPR_OFFSET_NAME(12),
+ GPR_OFFSET_NAME(13),
+ GPR_OFFSET_NAME(14),
+ GPR_OFFSET_NAME(15),
+ GPR_OFFSET_NAME(16),
+ GPR_OFFSET_NAME(17),
+ GPR_OFFSET_NAME(18),
+ GPR_OFFSET_NAME(19),
+ GPR_OFFSET_NAME(20),
+ GPR_OFFSET_NAME(21),
+ GPR_OFFSET_NAME(22),
+ GPR_OFFSET_NAME(23),
+ GPR_OFFSET_NAME(24),
+ GPR_OFFSET_NAME(25),
+ GPR_OFFSET_NAME(26),
+ GPR_OFFSET_NAME(27),
+ GPR_OFFSET_NAME(28),
+ GPR_OFFSET_NAME(29),
+ GPR_OFFSET_NAME(30),
+ {.name = "lr", .offset = offsetof(struct pt_regs, regs[30])},
+ REG_OFFSET_NAME(sp),
+ REG_OFFSET_NAME(pc),
+ REG_OFFSET_NAME(pstate),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (!strcmp(roff->name, name))
+ return roff->offset;
+ return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its offset
+ * @offset: the offset of a register in struct pt_regs.
+ *
+ * regs_query_register_name() returns the name of a register from its
+ * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
+ */
+const char *regs_query_register_name(unsigned int offset)
+{
+ const struct pt_regs_offset *roff;
+
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (roff->offset == offset)
+ return roff->name;
+ return NULL;
+}
+
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @addr: address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
+{
+ return ((addr & ~(THREAD_SIZE - 1)) ==
+ (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1))) ||
+ on_irq_stack(addr, raw_smp_processor_id());
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */
+unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
+{
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+ addr += n;
+ if (regs_within_kernel_stack(regs, (unsigned long)addr))
+ return *addr;
+ else
+ return 0;
+}
+
/*
* TODO: does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 02/10] arm64: Add more test functions to insn.c
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: "David A. Long" <dave.long@linaro.org>
Certain instructions are hard to execute correctly out-of-line (as in
kprobes). Test functions are added to insn.[hc] to identify these. The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/insn.h | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/insn.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 70 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..497f7a2 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -120,6 +120,29 @@ enum aarch64_insn_register {
AARCH64_INSN_REG_SP = 31 /* Stack pointer: as load/store base reg */
};
+enum aarch64_insn_special_register {
+ AARCH64_INSN_SPCLREG_SPSR_EL1 = 0xC200,
+ AARCH64_INSN_SPCLREG_ELR_EL1 = 0xC201,
+ AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208,
+ AARCH64_INSN_SPCLREG_SPSEL = 0xC210,
+ AARCH64_INSN_SPCLREG_CURRENTEL = 0xC212,
+ AARCH64_INSN_SPCLREG_DAIF = 0xDA11,
+ AARCH64_INSN_SPCLREG_NZCV = 0xDA10,
+ AARCH64_INSN_SPCLREG_FPCR = 0xDA20,
+ AARCH64_INSN_SPCLREG_DSPSR_EL0 = 0xDA28,
+ AARCH64_INSN_SPCLREG_DLR_EL0 = 0xDA29,
+ AARCH64_INSN_SPCLREG_SPSR_EL2 = 0xE200,
+ AARCH64_INSN_SPCLREG_ELR_EL2 = 0xE201,
+ AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208,
+ AARCH64_INSN_SPCLREG_SPSR_INQ = 0xE218,
+ AARCH64_INSN_SPCLREG_SPSR_ABT = 0xE219,
+ AARCH64_INSN_SPCLREG_SPSR_UND = 0xE21A,
+ AARCH64_INSN_SPCLREG_SPSR_FIQ = 0xE21B,
+ AARCH64_INSN_SPCLREG_SPSR_EL3 = 0xF200,
+ AARCH64_INSN_SPCLREG_ELR_EL3 = 0xF201,
+ AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210
+};
+
enum aarch64_insn_variant {
AARCH64_INSN_VARIANT_32BIT,
AARCH64_INSN_VARIANT_64BIT
@@ -223,8 +246,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
{ return (val); }
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F000000, 0x10000000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF000000, 0xD8000000)
__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800)
__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000)
+__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000)
+__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000)
@@ -273,10 +301,15 @@ __AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD4000001)
__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD4000002)
__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD4000003)
__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD4200000)
+__AARCH64_INSN_FUNCS(exception, 0xFF000000, 0xD4000000)
__AARCH64_INSN_FUNCS(hint, 0xFFFFF01F, 0xD503201F)
__AARCH64_INSN_FUNCS(br, 0xFFFFFC1F, 0xD61F0000)
__AARCH64_INSN_FUNCS(blr, 0xFFFFFC1F, 0xD63F0000)
__AARCH64_INSN_FUNCS(ret, 0xFFFFFC1F, 0xD65F0000)
+__AARCH64_INSN_FUNCS(eret, 0xFFFFFFFF, 0xD69F03E0)
+__AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000)
+__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000)
#undef __AARCH64_INSN_FUNCS
@@ -286,6 +319,8 @@ bool aarch64_insn_is_branch_imm(u32 insn);
int aarch64_insn_read(void *addr, u32 *insnp);
int aarch64_insn_write(void *addr, u32 insn);
enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
u32 insn, u64 imm);
@@ -367,6 +402,7 @@ bool aarch32_insn_is_wide(u32 insn);
#define A32_RT_OFFSET 12
#define A32_RT2_OFFSET 0
+u32 aarch64_insn_extract_system_reg(u32 insn);
u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
u32 aarch32_insn_mcr_extract_opc2(u32 insn);
u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 368c082..28c6110f 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -162,6 +162,32 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32 insn)
aarch64_insn_is_nop(insn);
}
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+ /* ldr/ldrsw (literal), prfm */
+
+ return aarch64_insn_is_ldr_lit(insn) ||
+ aarch64_insn_is_ldrsw_lit(insn) ||
+ aarch64_insn_is_adr_adrp(insn) ||
+ aarch64_insn_is_prfm_lit(insn);
+}
+
+bool __kprobes aarch64_insn_is_branch(u32 insn)
+{
+ /* b, bl, cb*, tb*, b.cond, br, blr */
+
+ return aarch64_insn_is_b(insn) ||
+ aarch64_insn_is_bl(insn) ||
+ aarch64_insn_is_cbz(insn) ||
+ aarch64_insn_is_cbnz(insn) ||
+ aarch64_insn_is_tbz(insn) ||
+ aarch64_insn_is_tbnz(insn) ||
+ aarch64_insn_is_ret(insn) ||
+ aarch64_insn_is_br(insn) ||
+ aarch64_insn_is_blr(insn) ||
+ aarch64_insn_is_bcond(insn);
+}
+
/*
* ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
* Section B2.6.5 "Concurrent modification and execution of instructions":
@@ -1175,6 +1201,14 @@ u32 aarch64_set_branch_offset(u32 insn, s32 offset)
BUG();
}
+/*
+ * Extract the Op/CR data from a msr/mrs instruction.
+ */
+u32 aarch64_insn_extract_system_reg(u32 insn)
+{
+ return (insn & 0x1FFFE0) >> 5;
+}
+
bool aarch32_insn_is_wide(u32 insn)
{
return insn >= 0xe800;
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 02/10] arm64: Add more test functions to insn.c
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
Certain instructions are hard to execute correctly out-of-line (as in
kprobes). Test functions are added to insn.[hc] to identify these. The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/insn.h | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/insn.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 70 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..497f7a2 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -120,6 +120,29 @@ enum aarch64_insn_register {
AARCH64_INSN_REG_SP = 31 /* Stack pointer: as load/store base reg */
};
+enum aarch64_insn_special_register {
+ AARCH64_INSN_SPCLREG_SPSR_EL1 = 0xC200,
+ AARCH64_INSN_SPCLREG_ELR_EL1 = 0xC201,
+ AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208,
+ AARCH64_INSN_SPCLREG_SPSEL = 0xC210,
+ AARCH64_INSN_SPCLREG_CURRENTEL = 0xC212,
+ AARCH64_INSN_SPCLREG_DAIF = 0xDA11,
+ AARCH64_INSN_SPCLREG_NZCV = 0xDA10,
+ AARCH64_INSN_SPCLREG_FPCR = 0xDA20,
+ AARCH64_INSN_SPCLREG_DSPSR_EL0 = 0xDA28,
+ AARCH64_INSN_SPCLREG_DLR_EL0 = 0xDA29,
+ AARCH64_INSN_SPCLREG_SPSR_EL2 = 0xE200,
+ AARCH64_INSN_SPCLREG_ELR_EL2 = 0xE201,
+ AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208,
+ AARCH64_INSN_SPCLREG_SPSR_INQ = 0xE218,
+ AARCH64_INSN_SPCLREG_SPSR_ABT = 0xE219,
+ AARCH64_INSN_SPCLREG_SPSR_UND = 0xE21A,
+ AARCH64_INSN_SPCLREG_SPSR_FIQ = 0xE21B,
+ AARCH64_INSN_SPCLREG_SPSR_EL3 = 0xF200,
+ AARCH64_INSN_SPCLREG_ELR_EL3 = 0xF201,
+ AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210
+};
+
enum aarch64_insn_variant {
AARCH64_INSN_VARIANT_32BIT,
AARCH64_INSN_VARIANT_64BIT
@@ -223,8 +246,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
{ return (val); }
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F000000, 0x10000000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF000000, 0xD8000000)
__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800)
__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000)
+__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000)
+__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000)
@@ -273,10 +301,15 @@ __AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD4000001)
__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD4000002)
__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD4000003)
__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD4200000)
+__AARCH64_INSN_FUNCS(exception, 0xFF000000, 0xD4000000)
__AARCH64_INSN_FUNCS(hint, 0xFFFFF01F, 0xD503201F)
__AARCH64_INSN_FUNCS(br, 0xFFFFFC1F, 0xD61F0000)
__AARCH64_INSN_FUNCS(blr, 0xFFFFFC1F, 0xD63F0000)
__AARCH64_INSN_FUNCS(ret, 0xFFFFFC1F, 0xD65F0000)
+__AARCH64_INSN_FUNCS(eret, 0xFFFFFFFF, 0xD69F03E0)
+__AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000)
+__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000)
#undef __AARCH64_INSN_FUNCS
@@ -286,6 +319,8 @@ bool aarch64_insn_is_branch_imm(u32 insn);
int aarch64_insn_read(void *addr, u32 *insnp);
int aarch64_insn_write(void *addr, u32 insn);
enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
u32 insn, u64 imm);
@@ -367,6 +402,7 @@ bool aarch32_insn_is_wide(u32 insn);
#define A32_RT_OFFSET 12
#define A32_RT2_OFFSET 0
+u32 aarch64_insn_extract_system_reg(u32 insn);
u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
u32 aarch32_insn_mcr_extract_opc2(u32 insn);
u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 368c082..28c6110f 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -162,6 +162,32 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32 insn)
aarch64_insn_is_nop(insn);
}
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+ /* ldr/ldrsw (literal), prfm */
+
+ return aarch64_insn_is_ldr_lit(insn) ||
+ aarch64_insn_is_ldrsw_lit(insn) ||
+ aarch64_insn_is_adr_adrp(insn) ||
+ aarch64_insn_is_prfm_lit(insn);
+}
+
+bool __kprobes aarch64_insn_is_branch(u32 insn)
+{
+ /* b, bl, cb*, tb*, b.cond, br, blr */
+
+ return aarch64_insn_is_b(insn) ||
+ aarch64_insn_is_bl(insn) ||
+ aarch64_insn_is_cbz(insn) ||
+ aarch64_insn_is_cbnz(insn) ||
+ aarch64_insn_is_tbz(insn) ||
+ aarch64_insn_is_tbnz(insn) ||
+ aarch64_insn_is_ret(insn) ||
+ aarch64_insn_is_br(insn) ||
+ aarch64_insn_is_blr(insn) ||
+ aarch64_insn_is_bcond(insn);
+}
+
/*
* ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
* Section B2.6.5 "Concurrent modification and execution of instructions":
@@ -1175,6 +1201,14 @@ u32 aarch64_set_branch_offset(u32 insn, s32 offset)
BUG();
}
+/*
+ * Extract the Op/CR data from a msr/mrs instruction.
+ */
+u32 aarch64_insn_extract_system_reg(u32 insn)
+{
+ return (insn & 0x1FFFE0) >> 5;
+}
+
bool aarch32_insn_is_wide(u32 insn)
{
return insn >= 0xe800;
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 03/10] arm64: add conditional instruction simulation support
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: "David A. Long" <dave.long@linaro.org>
Cease using the arm32 arm_check_condition() function and replace it with
a local version for use in deprecated instruction support on arm64. Also
make the function table used by this available for future use by kprobes
and/or uprobes.
This function is derived from code written by Sandeepa Prabhu.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/insn.h | 3 ++
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/armv8_deprecated.c | 19 ++++++-
arch/arm64/kernel/insn.c | 98 ++++++++++++++++++++++++++++++++++++
4 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 497f7a2..a44abbd 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -406,6 +406,9 @@ u32 aarch64_insn_extract_system_reg(u32 insn);
u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
u32 aarch32_insn_mcr_extract_opc2(u32 insn);
u32 aarch32_insn_mcr_extract_crm(u32 insn);
+
+typedef bool (pstate_check_t)(unsigned long);
+extern pstate_check_t * const aarch32_opcode_cond_checks[16];
#endif /* __ASSEMBLY__ */
#endif /* __ASM_INSN_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 2173149..4653aca 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -26,8 +26,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,objcopy)
arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
- sys_compat.o entry32.o \
- ../../arm/kernel/opcodes.o
+ sys_compat.o entry32.o
arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index c37202c..2934894 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -366,6 +366,21 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
return res;
}
+#define ARM_OPCODE_CONDITION_UNCOND 0xf
+
+static unsigned int __kprobes aarch32_check_condition(u32 opcode, u32 psr)
+{
+ u32 cc_bits = opcode >> 28;
+
+ if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
+ if ((*aarch32_opcode_cond_checks[cc_bits])(psr))
+ return ARM_OPCODE_CONDTEST_PASS;
+ else
+ return ARM_OPCODE_CONDTEST_FAIL;
+ }
+ return ARM_OPCODE_CONDTEST_UNCOND;
+}
+
/*
* swp_handler logs the id of calling process, dissects the instruction, sanity
* checks the memory location, calls emulate_swpX for the actual operation and
@@ -380,7 +395,7 @@ static int swp_handler(struct pt_regs *regs, u32 instr)
type = instr & TYPE_SWPB;
- switch (arm_check_condition(instr, regs->pstate)) {
+ switch (aarch32_check_condition(instr, regs->pstate)) {
case ARM_OPCODE_CONDTEST_PASS:
break;
case ARM_OPCODE_CONDTEST_FAIL:
@@ -461,7 +476,7 @@ static int cp15barrier_handler(struct pt_regs *regs, u32 instr)
{
perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, 1, regs, regs->pc);
- switch (arm_check_condition(instr, regs->pstate)) {
+ switch (aarch32_check_condition(instr, regs->pstate)) {
case ARM_OPCODE_CONDTEST_PASS:
break;
case ARM_OPCODE_CONDTEST_FAIL:
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 28c6110f..5cb2f3d 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -1234,3 +1234,101 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
{
return insn & CRM_MASK;
}
+
+static bool __kprobes __check_eq(unsigned long pstate)
+{
+ return (pstate & PSR_Z_BIT) != 0;
+}
+
+static bool __kprobes __check_ne(unsigned long pstate)
+{
+ return (pstate & PSR_Z_BIT) == 0;
+}
+
+static bool __kprobes __check_cs(unsigned long pstate)
+{
+ return (pstate & PSR_C_BIT) != 0;
+}
+
+static bool __kprobes __check_cc(unsigned long pstate)
+{
+ return (pstate & PSR_C_BIT) == 0;
+}
+
+static bool __kprobes __check_mi(unsigned long pstate)
+{
+ return (pstate & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_pl(unsigned long pstate)
+{
+ return (pstate & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_vs(unsigned long pstate)
+{
+ return (pstate & PSR_V_BIT) != 0;
+}
+
+static bool __kprobes __check_vc(unsigned long pstate)
+{
+ return (pstate & PSR_V_BIT) == 0;
+}
+
+static bool __kprobes __check_hi(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return (pstate & PSR_C_BIT) != 0;
+}
+
+static bool __kprobes __check_ls(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return (pstate & PSR_C_BIT) == 0;
+}
+
+static bool __kprobes __check_ge(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return (pstate & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_lt(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return (pstate & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_gt(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return (temp & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_le(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return (temp & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_al(unsigned long pstate)
+{
+ return true;
+}
+
+/*
+ * Note that the ARMv8 ARM calls condition code 0b1111 "nv", but states that
+ * it behaves identically to 0b1110 ("al").
+ */
+pstate_check_t * const aarch32_opcode_cond_checks[16] = {
+ __check_eq, __check_ne, __check_cs, __check_cc,
+ __check_mi, __check_pl, __check_vs, __check_vc,
+ __check_hi, __check_ls, __check_ge, __check_lt,
+ __check_gt, __check_le, __check_al, __check_al
+};
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 03/10] arm64: add conditional instruction simulation support
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
Cease using the arm32 arm_check_condition() function and replace it with
a local version for use in deprecated instruction support on arm64. Also
make the function table used by this available for future use by kprobes
and/or uprobes.
This function is derived from code written by Sandeepa Prabhu.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/insn.h | 3 ++
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/armv8_deprecated.c | 19 ++++++-
arch/arm64/kernel/insn.c | 98 ++++++++++++++++++++++++++++++++++++
4 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 497f7a2..a44abbd 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -406,6 +406,9 @@ u32 aarch64_insn_extract_system_reg(u32 insn);
u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
u32 aarch32_insn_mcr_extract_opc2(u32 insn);
u32 aarch32_insn_mcr_extract_crm(u32 insn);
+
+typedef bool (pstate_check_t)(unsigned long);
+extern pstate_check_t * const aarch32_opcode_cond_checks[16];
#endif /* __ASSEMBLY__ */
#endif /* __ASM_INSN_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 2173149..4653aca 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -26,8 +26,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,objcopy)
arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
- sys_compat.o entry32.o \
- ../../arm/kernel/opcodes.o
+ sys_compat.o entry32.o
arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index c37202c..2934894 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -366,6 +366,21 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
return res;
}
+#define ARM_OPCODE_CONDITION_UNCOND 0xf
+
+static unsigned int __kprobes aarch32_check_condition(u32 opcode, u32 psr)
+{
+ u32 cc_bits = opcode >> 28;
+
+ if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
+ if ((*aarch32_opcode_cond_checks[cc_bits])(psr))
+ return ARM_OPCODE_CONDTEST_PASS;
+ else
+ return ARM_OPCODE_CONDTEST_FAIL;
+ }
+ return ARM_OPCODE_CONDTEST_UNCOND;
+}
+
/*
* swp_handler logs the id of calling process, dissects the instruction, sanity
* checks the memory location, calls emulate_swpX for the actual operation and
@@ -380,7 +395,7 @@ static int swp_handler(struct pt_regs *regs, u32 instr)
type = instr & TYPE_SWPB;
- switch (arm_check_condition(instr, regs->pstate)) {
+ switch (aarch32_check_condition(instr, regs->pstate)) {
case ARM_OPCODE_CONDTEST_PASS:
break;
case ARM_OPCODE_CONDTEST_FAIL:
@@ -461,7 +476,7 @@ static int cp15barrier_handler(struct pt_regs *regs, u32 instr)
{
perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS, 1, regs, regs->pc);
- switch (arm_check_condition(instr, regs->pstate)) {
+ switch (aarch32_check_condition(instr, regs->pstate)) {
case ARM_OPCODE_CONDTEST_PASS:
break;
case ARM_OPCODE_CONDTEST_FAIL:
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 28c6110f..5cb2f3d 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -1234,3 +1234,101 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
{
return insn & CRM_MASK;
}
+
+static bool __kprobes __check_eq(unsigned long pstate)
+{
+ return (pstate & PSR_Z_BIT) != 0;
+}
+
+static bool __kprobes __check_ne(unsigned long pstate)
+{
+ return (pstate & PSR_Z_BIT) == 0;
+}
+
+static bool __kprobes __check_cs(unsigned long pstate)
+{
+ return (pstate & PSR_C_BIT) != 0;
+}
+
+static bool __kprobes __check_cc(unsigned long pstate)
+{
+ return (pstate & PSR_C_BIT) == 0;
+}
+
+static bool __kprobes __check_mi(unsigned long pstate)
+{
+ return (pstate & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_pl(unsigned long pstate)
+{
+ return (pstate & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_vs(unsigned long pstate)
+{
+ return (pstate & PSR_V_BIT) != 0;
+}
+
+static bool __kprobes __check_vc(unsigned long pstate)
+{
+ return (pstate & PSR_V_BIT) == 0;
+}
+
+static bool __kprobes __check_hi(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return (pstate & PSR_C_BIT) != 0;
+}
+
+static bool __kprobes __check_ls(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return (pstate & PSR_C_BIT) == 0;
+}
+
+static bool __kprobes __check_ge(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return (pstate & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_lt(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return (pstate & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_gt(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return (temp & PSR_N_BIT) == 0;
+}
+
+static bool __kprobes __check_le(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return (temp & PSR_N_BIT) != 0;
+}
+
+static bool __kprobes __check_al(unsigned long pstate)
+{
+ return true;
+}
+
+/*
+ * Note that the ARMv8 ARM calls condition code 0b1111 "nv", but states that
+ * it behaves identically to 0b1110 ("al").
+ */
+pstate_check_t * const aarch32_opcode_cond_checks[16] = {
+ __check_eq, __check_ne, __check_cs, __check_cc,
+ __check_mi, __check_pl, __check_vs, __check_vc,
+ __check_hi, __check_ls, __check_ge, __check_lt,
+ __check_gt, __check_le, __check_al, __check_al
+};
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.
Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.
A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.
ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.
Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).
Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.
Instructions generating exceptions or cpu mode change are rejected
for probing.
Exclusive load/store instructions are rejected too. Additionally, the
code is checked to see if it is inside an exclusive load/store sequence
(code from Pratyush).
System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.
This also changes arch/arm64/include/asm/ptrace.h to use
include/asm-generic/ptrace.h.
Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/debug-monitors.h | 5 +
arch/arm64/include/asm/insn.h | 2 +
arch/arm64/include/asm/kprobes.h | 60 ++++
arch/arm64/include/asm/probes.h | 34 +++
arch/arm64/include/asm/ptrace.h | 14 +-
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/debug-monitors.c | 16 +-
arch/arm64/kernel/probes/Makefile | 1 +
arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
arch/arm64/kernel/probes/decode-insn.h | 34 +++
arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
arch/arm64/mm/fault.c | 26 ++
14 files changed, 859 insertions(+), 5 deletions(-)
create mode 100644 arch/arm64/include/asm/kprobes.h
create mode 100644 arch/arm64/include/asm/probes.h
create mode 100644 arch/arm64/kernel/probes/Makefile
create mode 100644 arch/arm64/kernel/probes/decode-insn.c
create mode 100644 arch/arm64/kernel/probes/decode-insn.h
create mode 100644 arch/arm64/kernel/probes/kprobes.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fab133c..1f7d644 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -88,6 +88,7 @@ config ARM64
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
+ select HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 2fcb9b7..4b6b3f7 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -66,6 +66,11 @@
#define CACHE_FLUSH_IS_SAFE 1
+/* kprobes BRK opcodes with ESR encoding */
+#define BRK64_ESR_MASK 0xFFFF
+#define BRK64_ESR_KPROBES 0x0004
+#define BRK64_OPCODE_KPROBES (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+
/* AArch32 */
#define DBG_ESR_EVT_BKPT 0x4
#define DBG_ESR_EVT_VECC 0x5
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index a44abbd..1dbaa90 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -253,6 +253,8 @@ __AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000)
__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000)
__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000)
+__AARCH64_INSN_FUNCS(load_ex, 0x3F400000, 0x08400000)
+__AARCH64_INSN_FUNCS(store_ex, 0x3F400000, 0x08000000)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000)
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 0000000..79c9511
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,60 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include <linux/types.h>
+#include <linux/ptrace.h>
+#include <linux/percpu.h>
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 1
+#define MAX_STACK_SIZE 128
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include <asm/probes.h>
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_irqflag;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+ struct pt_regs jprobe_saved_regs;
+ char jprobes_stack[MAX_STACK_SIZE];
+};
+
+void arch_remove_kprobe(struct kprobe *);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
+int kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data);
+int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
+int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+
+#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
new file mode 100644
index 0000000..1e8a21a
--- /dev/null
+++ b/arch/arm64/include/asm/probes.h
@@ -0,0 +1,34 @@
+/*
+ * arch/arm64/include/asm/probes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#ifndef _ARM_PROBES_H
+#define _ARM_PROBES_H
+
+struct kprobe;
+struct arch_specific_insn;
+
+typedef u32 kprobe_opcode_t;
+typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
+typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_specific_insn {
+ kprobe_opcode_t *insn;
+ kprobes_pstate_check_t *pstate_cc;
+ kprobes_handler_t *handler;
+ /* restore address after step xol */
+ unsigned long restore;
+};
+
+#endif
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 6c0c7d3..8d74784 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -147,9 +147,12 @@ struct pt_regs {
#define fast_interrupts_enabled(regs) \
(!((regs)->pstate & PSR_F_BIT))
-#define user_stack_pointer(regs) \
+#define GET_USP(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
+#define SET_USP(ptregs, value) \
+ (!compat_user_mode(regs) ? ((regs)->sp = value) : ((regs)->compat_sp = value))
+
extern int regs_query_register_offset(const char *name);
extern const char *regs_query_register_name(unsigned int offset);
extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
@@ -208,8 +211,15 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
struct task_struct;
int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
-#define instruction_pointer(regs) ((unsigned long)(regs)->pc)
+#define GET_IP(regs) ((unsigned long)(regs)->pc)
+#define SET_IP(regs, value) ((regs)->pc = ((u64) (value)))
+
+#define GET_FP(ptregs) ((unsigned long)(ptregs)->regs[29])
+#define SET_FP(ptregs, value) ((ptregs)->regs[29] = ((u64) (value)))
+
+#include <asm-generic/ptrace.h>
+#undef profile_pc
extern unsigned long profile_pc(struct pt_regs *regs);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 4653aca..367673e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -46,7 +46,7 @@ arm64-obj-$(CONFIG_PARAVIRT) += paravirt.o
arm64-obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
arm64-obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
-obj-y += $(arm64-obj-y) vdso/
+obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
head-y := head.o
extra-y += $(head-y) vmlinux.lds
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 4fbf3c5..395de61 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -23,6 +23,7 @@
#include <linux/hardirq.h>
#include <linux/init.h>
#include <linux/ptrace.h>
+#include <linux/kprobes.h>
#include <linux/stat.h>
#include <linux/uaccess.h>
@@ -266,6 +267,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
*/
user_rewind_single_step(current);
} else {
+#ifdef CONFIG_KPROBES
+ if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
+ return 0;
+#endif
if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
return 0;
@@ -322,8 +327,15 @@ static int brk_handler(unsigned long addr, unsigned int esr,
{
if (user_mode(regs)) {
send_user_sigtrap(TRAP_BRKPT);
- } else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
- pr_warning("Unexpected kernel BRK exception at EL1\n");
+ }
+#ifdef CONFIG_KPROBES
+ else if ((esr & BRK64_ESR_MASK) == BRK64_ESR_KPROBES) {
+ if (kprobe_breakpoint_handler(regs, esr) != DBG_HOOK_HANDLED)
+ return -EFAULT;
+ }
+#endif
+ else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
+ pr_warn("Unexpected kernel BRK exception at EL1\n");
return -EFAULT;
}
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
new file mode 100644
index 0000000..bc159bf
--- /dev/null
+++ b/arch/arm64/kernel/probes/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o
diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
new file mode 100644
index 0000000..95c0c52
--- /dev/null
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -0,0 +1,143 @@
+/*
+ * arch/arm64/kernel/probes/decode-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <asm/kprobes.h>
+#include <asm/insn.h>
+#include <asm/sections.h>
+
+#include "decode-insn.h"
+
+static bool __kprobes aarch64_insn_is_steppable(u32 insn)
+{
+ /*
+ * Branch instructions will write a new value into the PC which is
+ * likely to be relative to the XOL address and therefore invalid.
+ * Deliberate generation of an exception during stepping is also not
+ * currently safe. Lastly, MSR instructions can do any number of nasty
+ * things we can't handle during single-stepping.
+ */
+ if (aarch64_get_insn_class(insn) == AARCH64_INSN_CLS_BR_SYS) {
+ if (aarch64_insn_is_branch(insn) ||
+ aarch64_insn_is_msr_imm(insn) ||
+ aarch64_insn_is_msr_reg(insn) ||
+ aarch64_insn_is_exception(insn) ||
+ aarch64_insn_is_eret(insn))
+ return false;
+
+ /*
+ * The MRS instruction may not return a correct value when
+ * executing in the single-stepping environment. We do make one
+ * exception, for reading the DAIF bits.
+ */
+ if (aarch64_insn_is_mrs(insn))
+ return aarch64_insn_extract_system_reg(insn)
+ != AARCH64_INSN_SPCLREG_DAIF;
+
+ /*
+ * The HINT instruction is is problematic when single-stepping,
+ * except for the NOP case.
+ */
+ if (aarch64_insn_is_hint(insn))
+ return aarch64_insn_is_nop(insn);
+
+ return true;
+ }
+
+ /*
+ * Instructions which load PC relative literals are not going to work
+ * when executed from an XOL slot. Instructions doing an exclusive
+ * load/store are not going to complete successfully when single-step
+ * exception handling happens in the middle of the sequence.
+ */
+ if (aarch64_insn_uses_literal(insn) ||
+ aarch64_insn_is_exclusive(insn))
+ return false;
+
+ return true;
+}
+
+/* Return:
+ * INSN_REJECTED If instruction is one not allowed to kprobe,
+ * INSN_GOOD If instruction is supported and uses instruction slot,
+ */
+static enum kprobe_insn __kprobes
+arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
+{
+ /*
+ * Instructions reading or modifying the PC won't work from the XOL
+ * slot.
+ */
+ if (aarch64_insn_is_steppable(insn))
+ return INSN_GOOD;
+ else
+ return INSN_REJECTED;
+}
+
+static bool __kprobes
+is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end)
+{
+ while (scan_start > scan_end) {
+ /*
+ * atomic region starts from exclusive load and ends with
+ * exclusive store.
+ */
+ if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start)))
+ return false;
+ else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start)))
+ return true;
+ scan_start--;
+ }
+
+ return false;
+}
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
+{
+ enum kprobe_insn decoded;
+ kprobe_opcode_t insn = le32_to_cpu(*addr);
+ kprobe_opcode_t *scan_start = addr - 1;
+ kprobe_opcode_t *scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+ struct module *mod;
+#endif
+
+ if (addr >= (kprobe_opcode_t *)_text &&
+ scan_end < (kprobe_opcode_t *)_text)
+ scan_end = (kprobe_opcode_t *)_text;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+ else {
+ preempt_disable();
+ mod = __module_address((unsigned long)addr);
+ if (mod && within_module_init((unsigned long)addr, mod) &&
+ !within_module_init((unsigned long)scan_end, mod))
+ scan_end = (kprobe_opcode_t *)mod->init_layout.base;
+ else if (mod && within_module_core((unsigned long)addr, mod) &&
+ !within_module_core((unsigned long)scan_end, mod))
+ scan_end = (kprobe_opcode_t *)mod->core_layout.base;
+ preempt_enable();
+ }
+#endif
+ decoded = arm_probe_decode_insn(insn, asi);
+
+ if (decoded == INSN_REJECTED ||
+ is_probed_address_atomic(scan_start, scan_end))
+ return INSN_REJECTED;
+
+ return decoded;
+}
diff --git a/arch/arm64/kernel/probes/decode-insn.h b/arch/arm64/kernel/probes/decode-insn.h
new file mode 100644
index 0000000..ad5ba9c
--- /dev/null
+++ b/arch/arm64/kernel/probes/decode-insn.h
@@ -0,0 +1,34 @@
+/*
+ * arch/arm64/kernel/probes/decode-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_ARM64_H
+#define _ARM_KERNEL_KPROBES_ARM64_H
+
+/*
+ * ARM strongly recommends a limit of 128 bytes between LoadExcl and
+ * StoreExcl instructions in a single thread of execution. So keep the
+ * max atomic context size as 32.
+ */
+#define MAX_ATOMIC_CONTEXT_SIZE (128 / sizeof(kprobe_opcode_t))
+
+enum kprobe_insn {
+ INSN_REJECTED,
+ INSN_GOOD,
+};
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi);
+
+#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
new file mode 100644
index 0000000..4496801
--- /dev/null
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -0,0 +1,525 @@
+/*
+ * arch/arm64/kernel/probes/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/stop_machine.h>
+#include <linux/stringify.h>
+#include <asm/traps.h>
+#include <asm/ptrace.h>
+#include <asm/cacheflush.h>
+#include <asm/debug-monitors.h>
+#include <asm/system_misc.h>
+#include <asm/insn.h>
+#include <asm/uaccess.h>
+#include <asm/irq.h>
+
+#include "decode-insn.h"
+
+#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
+ min((unsigned long)IRQ_STACK_SIZE, \
+ IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
+ min((unsigned long)MAX_STACK_SIZE, \
+ (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+
+void jprobe_return_break(void);
+
+DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
+DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+
+static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+{
+ /* prepare insn slot */
+ p->ainsn.insn[0] = cpu_to_le32(p->opcode);
+
+ flush_icache_range((uintptr_t) (p->ainsn.insn),
+ (uintptr_t) (p->ainsn.insn) +
+ MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
+
+ /*
+ * Needs restoring of return address after stepping xol.
+ */
+ p->ainsn.restore = (unsigned long) p->addr +
+ sizeof(kprobe_opcode_t);
+}
+
+int __kprobes arch_prepare_kprobe(struct kprobe *p)
+{
+ unsigned long probe_addr = (unsigned long)p->addr;
+ extern char __start_rodata[];
+ extern char __end_rodata[];
+
+ if (probe_addr & 0x3)
+ return -EINVAL;
+
+ /* copy instruction */
+ p->opcode = le32_to_cpu(*p->addr);
+
+ if (in_exception_text(probe_addr))
+ return -EINVAL;
+ if (probe_addr >= (unsigned long) __start_rodata &&
+ probe_addr <= (unsigned long) __end_rodata)
+ return -EINVAL;
+
+ /* decode instruction */
+ switch (arm_kprobe_decode_insn(p->addr, &p->ainsn)) {
+ case INSN_REJECTED: /* insn not supported */
+ return -EINVAL;
+
+ case INSN_GOOD: /* instruction uses slot */
+ p->ainsn.insn = get_insn_slot();
+ if (!p->ainsn.insn)
+ return -ENOMEM;
+ break;
+ };
+
+ /* prepare the instruction */
+ arch_prepare_ss_slot(p);
+
+ return 0;
+}
+
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+ void *addrs[1];
+ u32 insns[1];
+
+ addrs[0] = (void *)addr;
+ insns[0] = (u32)opcode;
+
+ return aarch64_insn_patch_text(addrs, insns, 1);
+}
+
+/* arm kprobe: install breakpoint in text */
+void __kprobes arch_arm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, BRK64_OPCODE_KPROBES);
+}
+
+/* disarm kprobe: remove breakpoint from text */
+void __kprobes arch_disarm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, p->opcode);
+}
+
+void __kprobes arch_remove_kprobe(struct kprobe *p)
+{
+ if (p->ainsn.insn) {
+ free_insn_slot(p->ainsn.insn, 0);
+ p->ainsn.insn = NULL;
+ }
+}
+
+static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ kcb->prev_kprobe.kp = kprobe_running();
+ kcb->prev_kprobe.status = kcb->kprobe_status;
+}
+
+static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ __this_cpu_write(current_kprobe, kcb->prev_kprobe.kp);
+ kcb->kprobe_status = kcb->prev_kprobe.status;
+}
+
+static void __kprobes set_current_kprobe(struct kprobe *p)
+{
+ __this_cpu_write(current_kprobe, p);
+}
+
+/*
+ * The D-flag (Debug mask) is set (masked) upon debug exception entry.
+ * Kprobes needs to clear (unmask) D-flag -ONLY- in case of recursive
+ * probe i.e. when probe hit from kprobe handler context upon
+ * executing the pre/post handlers. In this case we return with
+ * D-flag clear so that single-stepping can be carried-out.
+ *
+ * Leave D-flag set in all other cases.
+ */
+static void __kprobes
+spsr_set_debug_flag(struct pt_regs *regs, int mask)
+{
+ unsigned long spsr = regs->pstate;
+
+ if (mask)
+ spsr |= PSR_D_BIT;
+ else
+ spsr &= ~PSR_D_BIT;
+
+ regs->pstate = spsr;
+}
+
+/*
+ * Interrupts need to be disabled before single-step mode is set, and not
+ * reenabled until after single-step mode ends.
+ * Without disabling interrupt on local CPU, there is a chance of
+ * interrupt occurrence in the period of exception return and start of
+ * out-of-line single-step, that result in wrongly single stepping
+ * into the interrupt handler.
+ */
+static void __kprobes kprobes_save_local_irqflag(struct kprobe_ctlblk *kcb,
+ struct pt_regs *regs)
+{
+ kcb->saved_irqflag = regs->pstate;
+ regs->pstate |= PSR_I_BIT;
+}
+
+static void __kprobes kprobes_restore_local_irqflag(struct kprobe_ctlblk *kcb,
+ struct pt_regs *regs)
+{
+ if (kcb->saved_irqflag & PSR_I_BIT)
+ regs->pstate |= PSR_I_BIT;
+ else
+ regs->pstate &= ~PSR_I_BIT;
+}
+
+static void __kprobes
+set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ kcb->ss_ctx.ss_pending = true;
+ kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
+}
+
+static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
+{
+ kcb->ss_ctx.ss_pending = false;
+ kcb->ss_ctx.match_addr = 0;
+}
+
+static void __kprobes setup_singlestep(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb, int reenter)
+{
+ unsigned long slot;
+
+ if (reenter) {
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_REENTER;
+ } else {
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ }
+
+ BUG_ON(!p->ainsn.insn);
+
+ /* prepare for single stepping */
+ slot = (unsigned long)p->ainsn.insn;
+
+ set_ss_context(kcb, slot); /* mark pending ss */
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 0);
+
+ /* IRQs and single stepping do not mix well. */
+ kprobes_save_local_irqflag(kcb, regs);
+ kernel_enable_single_step(regs);
+ instruction_pointer_set(regs, slot);
+}
+
+static int __kprobes reenter_kprobe(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SSDONE:
+ case KPROBE_HIT_ACTIVE:
+ kprobes_inc_nmissed_count(p);
+ setup_singlestep(p, regs, kcb, 1);
+ break;
+ case KPROBE_HIT_SS:
+ case KPROBE_REENTER:
+ pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
+ dump_kprobe(p);
+ BUG();
+ break;
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+
+ return 1;
+}
+
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
+{
+ struct kprobe *cur = kprobe_running();
+
+ if (!cur)
+ return;
+
+ /* return addr restore if non-branching insn */
+ if (cur->ainsn.restore != 0)
+ instruction_pointer_set(regs, cur->ainsn.restore);
+
+ /* restore back original saved kprobe variables and continue */
+ if (kcb->kprobe_status == KPROBE_REENTER) {
+ restore_previous_kprobe(kcb);
+ return;
+ }
+ /* call post handler */
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ if (cur->post_handler) {
+ /* post_handler can hit breakpoint and single step
+ * again, so we enable D-flag for recursive exception.
+ */
+ cur->post_handler(cur, regs, 0);
+ }
+
+ reset_current_kprobe();
+}
+
+int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
+{
+ struct kprobe *cur = kprobe_running();
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SS:
+ case KPROBE_REENTER:
+ /*
+ * We are here because the instruction being single
+ * stepped caused a page fault. We reset the current
+ * kprobe and the ip points back to the probe address
+ * and allow the page fault handler to continue as a
+ * normal page fault.
+ */
+ instruction_pointer_set(regs, (unsigned long) cur->addr);
+ if (!instruction_pointer(regs))
+ BUG();
+
+ kernel_disable_single_step();
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 1);
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ restore_previous_kprobe(kcb);
+ else
+ reset_current_kprobe();
+
+ break;
+ case KPROBE_HIT_ACTIVE:
+ case KPROBE_HIT_SSDONE:
+ /*
+ * We increment the nmissed count for accounting,
+ * we can also use npre/npostfault count for accounting
+ * these specific fault cases.
+ */
+ kprobes_inc_nmissed_count(cur);
+
+ /*
+ * We come here because instructions in the pre/post
+ * handler caused the page_fault, this could happen
+ * if handler tries to access user space by
+ * copy_from_user(), get_user() etc. Let the
+ * user-specified handler try to fix it first.
+ */
+ if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
+ return 1;
+
+ /*
+ * In case the user-specified fault handler returned
+ * zero, try to fix up.
+ */
+ if (fixup_exception(regs))
+ return 1;
+ }
+ return 0;
+}
+
+int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data)
+{
+ return NOTIFY_DONE;
+}
+
+static void __kprobes kprobe_handler(struct pt_regs *regs)
+{
+ struct kprobe *p, *cur_kprobe;
+ struct kprobe_ctlblk *kcb;
+ unsigned long addr = instruction_pointer(regs);
+
+ kcb = get_kprobe_ctlblk();
+ cur_kprobe = kprobe_running();
+
+ p = get_kprobe((kprobe_opcode_t *) addr);
+
+ if (p) {
+ if (cur_kprobe) {
+ if (reenter_kprobe(p, regs, kcb))
+ return;
+ } else {
+ /* Probe hit */
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+
+ /*
+ * If we have no pre-handler or it returned 0, we
+ * continue with normal processing. If we have a
+ * pre-handler and it returned non-zero, it prepped
+ * for calling the break_handler below on re-entry,
+ * so get out doing nothing more here.
+ *
+ * pre_handler can hit a breakpoint and can step thru
+ * before return, keep PSTATE D-flag enabled until
+ * pre_handler return back.
+ */
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ setup_singlestep(p, regs, kcb, 0);
+ return;
+ }
+ }
+ } else if ((le32_to_cpu(*(kprobe_opcode_t *) addr) ==
+ BRK64_OPCODE_KPROBES) && cur_kprobe) {
+ /* We probably hit a jprobe. Call its break handler. */
+ if (cur_kprobe->break_handler &&
+ cur_kprobe->break_handler(cur_kprobe, regs)) {
+ setup_singlestep(cur_kprobe, regs, kcb, 0);
+ return;
+ }
+ }
+ /*
+ * The breakpoint instruction was removed right
+ * after we hit it. Another cpu has removed
+ * either a probepoint or a debugger breakpoint
+ * at this address. In either case, no further
+ * handling of this interrupt is appropriate.
+ * Return back to original instruction, and continue.
+ */
+}
+
+static int __kprobes
+kprobe_ss_hit(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ if ((kcb->ss_ctx.ss_pending)
+ && (kcb->ss_ctx.match_addr == addr)) {
+ clear_ss_context(kcb); /* clear pending ss */
+ return DBG_HOOK_HANDLED;
+ }
+ /* not ours, kprobes should ignore it */
+ return DBG_HOOK_ERROR;
+}
+
+int __kprobes
+kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ int retval;
+
+ /* return error if this is not our step */
+ retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
+
+ if (retval == DBG_HOOK_HANDLED) {
+ kprobes_restore_local_irqflag(kcb, regs);
+ kernel_disable_single_step();
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 1);
+
+ post_kprobe_handler(kcb, regs);
+ }
+
+ return retval;
+}
+
+int __kprobes
+kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
+{
+ kprobe_handler(regs);
+ return DBG_HOOK_HANDLED;
+}
+
+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_ptr = kernel_stack_pointer(regs);
+
+ kcb->jprobe_saved_regs = *regs;
+ /*
+ * As Linus pointed out, gcc assumes that the callee
+ * owns the argument space and could overwrite it, e.g.
+ * tailcall optimization. So, to be absolutely safe
+ * we also save and restore enough stack bytes to cover
+ * the argument area.
+ */
+ memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+ MIN_STACK_SIZE(stack_ptr));
+
+ instruction_pointer_set(regs, (unsigned long) jp->entry);
+ preempt_disable();
+ pause_graph_tracing();
+ return 1;
+}
+
+void __kprobes jprobe_return(void)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ /*
+ * Jprobe handler return by entering break exception,
+ * encoded same as kprobe, but with following conditions
+ * -a magic number in x0 to identify from rest of other kprobes.
+ * -restore stack addr to original saved pt_regs
+ */
+ asm volatile ("ldr x0, [%0]\n\t"
+ "mov sp, x0\n\t"
+ ".globl jprobe_return_break\n\t"
+ "jprobe_return_break:\n\t"
+ "brk %1\n\t"
+ :
+ : "r"(&kcb->jprobe_saved_regs.sp),
+ "I"(BRK64_ESR_KPROBES)
+ : "memory");
+}
+
+int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_addr = kcb->jprobe_saved_regs.sp;
+ long orig_sp = kernel_stack_pointer(regs);
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+
+ if (instruction_pointer(regs) != (u64) jprobe_return_break)
+ return 0;
+
+ if (orig_sp != stack_addr) {
+ struct pt_regs *saved_regs =
+ (struct pt_regs *)kcb->jprobe_saved_regs.sp;
+ pr_err("current sp %lx does not match saved sp %lx\n",
+ orig_sp, stack_addr);
+ pr_err("Saved registers for jprobe %p\n", jp);
+ show_regs(saved_regs);
+ pr_err("Current registers\n");
+ show_regs(regs);
+ BUG();
+ }
+ unpause_graph_tracing();
+ *regs = kcb->jprobe_saved_regs;
+ memcpy((void *)stack_addr, kcb->jprobes_stack,
+ MIN_STACK_SIZE(stack_addr));
+ preempt_enable_no_resched();
+ return 1;
+}
+
+int __init arch_init_kprobes(void)
+{
+ return 0;
+}
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 435e820..075ce32 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -121,6 +121,7 @@ SECTIONS
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
+ KPROBES_TEXT
HYPERVISOR_TEXT
IDMAP_TEXT
HIBERNATE_TEXT
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 013e2cb..2408e51 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -41,6 +41,28 @@
static const char *fault_name(unsigned int esr);
+#ifdef CONFIG_KPROBES
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+ int ret = 0;
+
+ /* kprobe_running() needs smp_processor_id() */
+ if (!user_mode(regs)) {
+ preempt_disable();
+ if (kprobe_running() && kprobe_fault_handler(regs, esr))
+ ret = 1;
+ preempt_enable();
+ }
+
+ return ret;
+}
+#else
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+ return 0;
+}
+#endif
+
/*
* Dump out the page tables associated with 'addr' in mm 'mm'.
*/
@@ -259,6 +281,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
unsigned long vm_flags = VM_READ | VM_WRITE | VM_EXEC;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ if (notify_page_fault(regs, esr))
+ return 0;
+
tsk = current;
mm = tsk->mm;
@@ -629,6 +654,7 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
return rv;
}
+NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
void cpu_enable_pan(void *__unused)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.
Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.
A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.
ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.
Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).
Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.
Instructions generating exceptions or cpu mode change are rejected
for probing.
Exclusive load/store instructions are rejected too. Additionally, the
code is checked to see if it is inside an exclusive load/store sequence
(code from Pratyush).
System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.
This also changes arch/arm64/include/asm/ptrace.h to use
include/asm-generic/ptrace.h.
Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/debug-monitors.h | 5 +
arch/arm64/include/asm/insn.h | 2 +
arch/arm64/include/asm/kprobes.h | 60 ++++
arch/arm64/include/asm/probes.h | 34 +++
arch/arm64/include/asm/ptrace.h | 14 +-
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/debug-monitors.c | 16 +-
arch/arm64/kernel/probes/Makefile | 1 +
arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
arch/arm64/kernel/probes/decode-insn.h | 34 +++
arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
arch/arm64/mm/fault.c | 26 ++
14 files changed, 859 insertions(+), 5 deletions(-)
create mode 100644 arch/arm64/include/asm/kprobes.h
create mode 100644 arch/arm64/include/asm/probes.h
create mode 100644 arch/arm64/kernel/probes/Makefile
create mode 100644 arch/arm64/kernel/probes/decode-insn.c
create mode 100644 arch/arm64/kernel/probes/decode-insn.h
create mode 100644 arch/arm64/kernel/probes/kprobes.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fab133c..1f7d644 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -88,6 +88,7 @@ config ARM64
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
+ select HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 2fcb9b7..4b6b3f7 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -66,6 +66,11 @@
#define CACHE_FLUSH_IS_SAFE 1
+/* kprobes BRK opcodes with ESR encoding */
+#define BRK64_ESR_MASK 0xFFFF
+#define BRK64_ESR_KPROBES 0x0004
+#define BRK64_OPCODE_KPROBES (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+
/* AArch32 */
#define DBG_ESR_EVT_BKPT 0x4
#define DBG_ESR_EVT_VECC 0x5
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index a44abbd..1dbaa90 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -253,6 +253,8 @@ __AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000)
__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000)
__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000)
+__AARCH64_INSN_FUNCS(load_ex, 0x3F400000, 0x08400000)
+__AARCH64_INSN_FUNCS(store_ex, 0x3F400000, 0x08000000)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000)
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 0000000..79c9511
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,60 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include <linux/types.h>
+#include <linux/ptrace.h>
+#include <linux/percpu.h>
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 1
+#define MAX_STACK_SIZE 128
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include <asm/probes.h>
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+ unsigned long ss_pending;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ unsigned long saved_irqflag;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+ struct pt_regs jprobe_saved_regs;
+ char jprobes_stack[MAX_STACK_SIZE];
+};
+
+void arch_remove_kprobe(struct kprobe *);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
+int kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data);
+int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
+int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+
+#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
new file mode 100644
index 0000000..1e8a21a
--- /dev/null
+++ b/arch/arm64/include/asm/probes.h
@@ -0,0 +1,34 @@
+/*
+ * arch/arm64/include/asm/probes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#ifndef _ARM_PROBES_H
+#define _ARM_PROBES_H
+
+struct kprobe;
+struct arch_specific_insn;
+
+typedef u32 kprobe_opcode_t;
+typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
+typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
+
+/* architecture specific copy of original instruction */
+struct arch_specific_insn {
+ kprobe_opcode_t *insn;
+ kprobes_pstate_check_t *pstate_cc;
+ kprobes_handler_t *handler;
+ /* restore address after step xol */
+ unsigned long restore;
+};
+
+#endif
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 6c0c7d3..8d74784 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -147,9 +147,12 @@ struct pt_regs {
#define fast_interrupts_enabled(regs) \
(!((regs)->pstate & PSR_F_BIT))
-#define user_stack_pointer(regs) \
+#define GET_USP(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
+#define SET_USP(ptregs, value) \
+ (!compat_user_mode(regs) ? ((regs)->sp = value) : ((regs)->compat_sp = value))
+
extern int regs_query_register_offset(const char *name);
extern const char *regs_query_register_name(unsigned int offset);
extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
@@ -208,8 +211,15 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
struct task_struct;
int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
-#define instruction_pointer(regs) ((unsigned long)(regs)->pc)
+#define GET_IP(regs) ((unsigned long)(regs)->pc)
+#define SET_IP(regs, value) ((regs)->pc = ((u64) (value)))
+
+#define GET_FP(ptregs) ((unsigned long)(ptregs)->regs[29])
+#define SET_FP(ptregs, value) ((ptregs)->regs[29] = ((u64) (value)))
+
+#include <asm-generic/ptrace.h>
+#undef profile_pc
extern unsigned long profile_pc(struct pt_regs *regs);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 4653aca..367673e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -46,7 +46,7 @@ arm64-obj-$(CONFIG_PARAVIRT) += paravirt.o
arm64-obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
arm64-obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
-obj-y += $(arm64-obj-y) vdso/
+obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
head-y := head.o
extra-y += $(head-y) vmlinux.lds
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 4fbf3c5..395de61 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -23,6 +23,7 @@
#include <linux/hardirq.h>
#include <linux/init.h>
#include <linux/ptrace.h>
+#include <linux/kprobes.h>
#include <linux/stat.h>
#include <linux/uaccess.h>
@@ -266,6 +267,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
*/
user_rewind_single_step(current);
} else {
+#ifdef CONFIG_KPROBES
+ if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
+ return 0;
+#endif
if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
return 0;
@@ -322,8 +327,15 @@ static int brk_handler(unsigned long addr, unsigned int esr,
{
if (user_mode(regs)) {
send_user_sigtrap(TRAP_BRKPT);
- } else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
- pr_warning("Unexpected kernel BRK exception at EL1\n");
+ }
+#ifdef CONFIG_KPROBES
+ else if ((esr & BRK64_ESR_MASK) == BRK64_ESR_KPROBES) {
+ if (kprobe_breakpoint_handler(regs, esr) != DBG_HOOK_HANDLED)
+ return -EFAULT;
+ }
+#endif
+ else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
+ pr_warn("Unexpected kernel BRK exception at EL1\n");
return -EFAULT;
}
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
new file mode 100644
index 0000000..bc159bf
--- /dev/null
+++ b/arch/arm64/kernel/probes/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o
diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
new file mode 100644
index 0000000..95c0c52
--- /dev/null
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -0,0 +1,143 @@
+/*
+ * arch/arm64/kernel/probes/decode-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <asm/kprobes.h>
+#include <asm/insn.h>
+#include <asm/sections.h>
+
+#include "decode-insn.h"
+
+static bool __kprobes aarch64_insn_is_steppable(u32 insn)
+{
+ /*
+ * Branch instructions will write a new value into the PC which is
+ * likely to be relative to the XOL address and therefore invalid.
+ * Deliberate generation of an exception during stepping is also not
+ * currently safe. Lastly, MSR instructions can do any number of nasty
+ * things we can't handle during single-stepping.
+ */
+ if (aarch64_get_insn_class(insn) == AARCH64_INSN_CLS_BR_SYS) {
+ if (aarch64_insn_is_branch(insn) ||
+ aarch64_insn_is_msr_imm(insn) ||
+ aarch64_insn_is_msr_reg(insn) ||
+ aarch64_insn_is_exception(insn) ||
+ aarch64_insn_is_eret(insn))
+ return false;
+
+ /*
+ * The MRS instruction may not return a correct value when
+ * executing in the single-stepping environment. We do make one
+ * exception, for reading the DAIF bits.
+ */
+ if (aarch64_insn_is_mrs(insn))
+ return aarch64_insn_extract_system_reg(insn)
+ != AARCH64_INSN_SPCLREG_DAIF;
+
+ /*
+ * The HINT instruction is is problematic when single-stepping,
+ * except for the NOP case.
+ */
+ if (aarch64_insn_is_hint(insn))
+ return aarch64_insn_is_nop(insn);
+
+ return true;
+ }
+
+ /*
+ * Instructions which load PC relative literals are not going to work
+ * when executed from an XOL slot. Instructions doing an exclusive
+ * load/store are not going to complete successfully when single-step
+ * exception handling happens in the middle of the sequence.
+ */
+ if (aarch64_insn_uses_literal(insn) ||
+ aarch64_insn_is_exclusive(insn))
+ return false;
+
+ return true;
+}
+
+/* Return:
+ * INSN_REJECTED If instruction is one not allowed to kprobe,
+ * INSN_GOOD If instruction is supported and uses instruction slot,
+ */
+static enum kprobe_insn __kprobes
+arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
+{
+ /*
+ * Instructions reading or modifying the PC won't work from the XOL
+ * slot.
+ */
+ if (aarch64_insn_is_steppable(insn))
+ return INSN_GOOD;
+ else
+ return INSN_REJECTED;
+}
+
+static bool __kprobes
+is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end)
+{
+ while (scan_start > scan_end) {
+ /*
+ * atomic region starts from exclusive load and ends with
+ * exclusive store.
+ */
+ if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start)))
+ return false;
+ else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start)))
+ return true;
+ scan_start--;
+ }
+
+ return false;
+}
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
+{
+ enum kprobe_insn decoded;
+ kprobe_opcode_t insn = le32_to_cpu(*addr);
+ kprobe_opcode_t *scan_start = addr - 1;
+ kprobe_opcode_t *scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+ struct module *mod;
+#endif
+
+ if (addr >= (kprobe_opcode_t *)_text &&
+ scan_end < (kprobe_opcode_t *)_text)
+ scan_end = (kprobe_opcode_t *)_text;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+ else {
+ preempt_disable();
+ mod = __module_address((unsigned long)addr);
+ if (mod && within_module_init((unsigned long)addr, mod) &&
+ !within_module_init((unsigned long)scan_end, mod))
+ scan_end = (kprobe_opcode_t *)mod->init_layout.base;
+ else if (mod && within_module_core((unsigned long)addr, mod) &&
+ !within_module_core((unsigned long)scan_end, mod))
+ scan_end = (kprobe_opcode_t *)mod->core_layout.base;
+ preempt_enable();
+ }
+#endif
+ decoded = arm_probe_decode_insn(insn, asi);
+
+ if (decoded == INSN_REJECTED ||
+ is_probed_address_atomic(scan_start, scan_end))
+ return INSN_REJECTED;
+
+ return decoded;
+}
diff --git a/arch/arm64/kernel/probes/decode-insn.h b/arch/arm64/kernel/probes/decode-insn.h
new file mode 100644
index 0000000..ad5ba9c
--- /dev/null
+++ b/arch/arm64/kernel/probes/decode-insn.h
@@ -0,0 +1,34 @@
+/*
+ * arch/arm64/kernel/probes/decode-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_ARM64_H
+#define _ARM_KERNEL_KPROBES_ARM64_H
+
+/*
+ * ARM strongly recommends a limit of 128 bytes between LoadExcl and
+ * StoreExcl instructions in a single thread of execution. So keep the
+ * max atomic context size as 32.
+ */
+#define MAX_ATOMIC_CONTEXT_SIZE (128 / sizeof(kprobe_opcode_t))
+
+enum kprobe_insn {
+ INSN_REJECTED,
+ INSN_GOOD,
+};
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi);
+
+#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
new file mode 100644
index 0000000..4496801
--- /dev/null
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -0,0 +1,525 @@
+/*
+ * arch/arm64/kernel/probes/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/stop_machine.h>
+#include <linux/stringify.h>
+#include <asm/traps.h>
+#include <asm/ptrace.h>
+#include <asm/cacheflush.h>
+#include <asm/debug-monitors.h>
+#include <asm/system_misc.h>
+#include <asm/insn.h>
+#include <asm/uaccess.h>
+#include <asm/irq.h>
+
+#include "decode-insn.h"
+
+#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
+ min((unsigned long)IRQ_STACK_SIZE, \
+ IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
+ min((unsigned long)MAX_STACK_SIZE, \
+ (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+
+void jprobe_return_break(void);
+
+DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
+DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+
+static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+{
+ /* prepare insn slot */
+ p->ainsn.insn[0] = cpu_to_le32(p->opcode);
+
+ flush_icache_range((uintptr_t) (p->ainsn.insn),
+ (uintptr_t) (p->ainsn.insn) +
+ MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
+
+ /*
+ * Needs restoring of return address after stepping xol.
+ */
+ p->ainsn.restore = (unsigned long) p->addr +
+ sizeof(kprobe_opcode_t);
+}
+
+int __kprobes arch_prepare_kprobe(struct kprobe *p)
+{
+ unsigned long probe_addr = (unsigned long)p->addr;
+ extern char __start_rodata[];
+ extern char __end_rodata[];
+
+ if (probe_addr & 0x3)
+ return -EINVAL;
+
+ /* copy instruction */
+ p->opcode = le32_to_cpu(*p->addr);
+
+ if (in_exception_text(probe_addr))
+ return -EINVAL;
+ if (probe_addr >= (unsigned long) __start_rodata &&
+ probe_addr <= (unsigned long) __end_rodata)
+ return -EINVAL;
+
+ /* decode instruction */
+ switch (arm_kprobe_decode_insn(p->addr, &p->ainsn)) {
+ case INSN_REJECTED: /* insn not supported */
+ return -EINVAL;
+
+ case INSN_GOOD: /* instruction uses slot */
+ p->ainsn.insn = get_insn_slot();
+ if (!p->ainsn.insn)
+ return -ENOMEM;
+ break;
+ };
+
+ /* prepare the instruction */
+ arch_prepare_ss_slot(p);
+
+ return 0;
+}
+
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+ void *addrs[1];
+ u32 insns[1];
+
+ addrs[0] = (void *)addr;
+ insns[0] = (u32)opcode;
+
+ return aarch64_insn_patch_text(addrs, insns, 1);
+}
+
+/* arm kprobe: install breakpoint in text */
+void __kprobes arch_arm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, BRK64_OPCODE_KPROBES);
+}
+
+/* disarm kprobe: remove breakpoint from text */
+void __kprobes arch_disarm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, p->opcode);
+}
+
+void __kprobes arch_remove_kprobe(struct kprobe *p)
+{
+ if (p->ainsn.insn) {
+ free_insn_slot(p->ainsn.insn, 0);
+ p->ainsn.insn = NULL;
+ }
+}
+
+static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ kcb->prev_kprobe.kp = kprobe_running();
+ kcb->prev_kprobe.status = kcb->kprobe_status;
+}
+
+static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ __this_cpu_write(current_kprobe, kcb->prev_kprobe.kp);
+ kcb->kprobe_status = kcb->prev_kprobe.status;
+}
+
+static void __kprobes set_current_kprobe(struct kprobe *p)
+{
+ __this_cpu_write(current_kprobe, p);
+}
+
+/*
+ * The D-flag (Debug mask) is set (masked) upon debug exception entry.
+ * Kprobes needs to clear (unmask) D-flag -ONLY- in case of recursive
+ * probe i.e. when probe hit from kprobe handler context upon
+ * executing the pre/post handlers. In this case we return with
+ * D-flag clear so that single-stepping can be carried-out.
+ *
+ * Leave D-flag set in all other cases.
+ */
+static void __kprobes
+spsr_set_debug_flag(struct pt_regs *regs, int mask)
+{
+ unsigned long spsr = regs->pstate;
+
+ if (mask)
+ spsr |= PSR_D_BIT;
+ else
+ spsr &= ~PSR_D_BIT;
+
+ regs->pstate = spsr;
+}
+
+/*
+ * Interrupts need to be disabled before single-step mode is set, and not
+ * reenabled until after single-step mode ends.
+ * Without disabling interrupt on local CPU, there is a chance of
+ * interrupt occurrence in the period of exception return and start of
+ * out-of-line single-step, that result in wrongly single stepping
+ * into the interrupt handler.
+ */
+static void __kprobes kprobes_save_local_irqflag(struct kprobe_ctlblk *kcb,
+ struct pt_regs *regs)
+{
+ kcb->saved_irqflag = regs->pstate;
+ regs->pstate |= PSR_I_BIT;
+}
+
+static void __kprobes kprobes_restore_local_irqflag(struct kprobe_ctlblk *kcb,
+ struct pt_regs *regs)
+{
+ if (kcb->saved_irqflag & PSR_I_BIT)
+ regs->pstate |= PSR_I_BIT;
+ else
+ regs->pstate &= ~PSR_I_BIT;
+}
+
+static void __kprobes
+set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ kcb->ss_ctx.ss_pending = true;
+ kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
+}
+
+static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
+{
+ kcb->ss_ctx.ss_pending = false;
+ kcb->ss_ctx.match_addr = 0;
+}
+
+static void __kprobes setup_singlestep(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb, int reenter)
+{
+ unsigned long slot;
+
+ if (reenter) {
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_REENTER;
+ } else {
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ }
+
+ BUG_ON(!p->ainsn.insn);
+
+ /* prepare for single stepping */
+ slot = (unsigned long)p->ainsn.insn;
+
+ set_ss_context(kcb, slot); /* mark pending ss */
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 0);
+
+ /* IRQs and single stepping do not mix well. */
+ kprobes_save_local_irqflag(kcb, regs);
+ kernel_enable_single_step(regs);
+ instruction_pointer_set(regs, slot);
+}
+
+static int __kprobes reenter_kprobe(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SSDONE:
+ case KPROBE_HIT_ACTIVE:
+ kprobes_inc_nmissed_count(p);
+ setup_singlestep(p, regs, kcb, 1);
+ break;
+ case KPROBE_HIT_SS:
+ case KPROBE_REENTER:
+ pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
+ dump_kprobe(p);
+ BUG();
+ break;
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+
+ return 1;
+}
+
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
+{
+ struct kprobe *cur = kprobe_running();
+
+ if (!cur)
+ return;
+
+ /* return addr restore if non-branching insn */
+ if (cur->ainsn.restore != 0)
+ instruction_pointer_set(regs, cur->ainsn.restore);
+
+ /* restore back original saved kprobe variables and continue */
+ if (kcb->kprobe_status == KPROBE_REENTER) {
+ restore_previous_kprobe(kcb);
+ return;
+ }
+ /* call post handler */
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ if (cur->post_handler) {
+ /* post_handler can hit breakpoint and single step
+ * again, so we enable D-flag for recursive exception.
+ */
+ cur->post_handler(cur, regs, 0);
+ }
+
+ reset_current_kprobe();
+}
+
+int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
+{
+ struct kprobe *cur = kprobe_running();
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SS:
+ case KPROBE_REENTER:
+ /*
+ * We are here because the instruction being single
+ * stepped caused a page fault. We reset the current
+ * kprobe and the ip points back to the probe address
+ * and allow the page fault handler to continue as a
+ * normal page fault.
+ */
+ instruction_pointer_set(regs, (unsigned long) cur->addr);
+ if (!instruction_pointer(regs))
+ BUG();
+
+ kernel_disable_single_step();
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 1);
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ restore_previous_kprobe(kcb);
+ else
+ reset_current_kprobe();
+
+ break;
+ case KPROBE_HIT_ACTIVE:
+ case KPROBE_HIT_SSDONE:
+ /*
+ * We increment the nmissed count for accounting,
+ * we can also use npre/npostfault count for accounting
+ * these specific fault cases.
+ */
+ kprobes_inc_nmissed_count(cur);
+
+ /*
+ * We come here because instructions in the pre/post
+ * handler caused the page_fault, this could happen
+ * if handler tries to access user space by
+ * copy_from_user(), get_user() etc. Let the
+ * user-specified handler try to fix it first.
+ */
+ if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
+ return 1;
+
+ /*
+ * In case the user-specified fault handler returned
+ * zero, try to fix up.
+ */
+ if (fixup_exception(regs))
+ return 1;
+ }
+ return 0;
+}
+
+int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data)
+{
+ return NOTIFY_DONE;
+}
+
+static void __kprobes kprobe_handler(struct pt_regs *regs)
+{
+ struct kprobe *p, *cur_kprobe;
+ struct kprobe_ctlblk *kcb;
+ unsigned long addr = instruction_pointer(regs);
+
+ kcb = get_kprobe_ctlblk();
+ cur_kprobe = kprobe_running();
+
+ p = get_kprobe((kprobe_opcode_t *) addr);
+
+ if (p) {
+ if (cur_kprobe) {
+ if (reenter_kprobe(p, regs, kcb))
+ return;
+ } else {
+ /* Probe hit */
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+
+ /*
+ * If we have no pre-handler or it returned 0, we
+ * continue with normal processing. If we have a
+ * pre-handler and it returned non-zero, it prepped
+ * for calling the break_handler below on re-entry,
+ * so get out doing nothing more here.
+ *
+ * pre_handler can hit a breakpoint and can step thru
+ * before return, keep PSTATE D-flag enabled until
+ * pre_handler return back.
+ */
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ setup_singlestep(p, regs, kcb, 0);
+ return;
+ }
+ }
+ } else if ((le32_to_cpu(*(kprobe_opcode_t *) addr) ==
+ BRK64_OPCODE_KPROBES) && cur_kprobe) {
+ /* We probably hit a jprobe. Call its break handler. */
+ if (cur_kprobe->break_handler &&
+ cur_kprobe->break_handler(cur_kprobe, regs)) {
+ setup_singlestep(cur_kprobe, regs, kcb, 0);
+ return;
+ }
+ }
+ /*
+ * The breakpoint instruction was removed right
+ * after we hit it. Another cpu has removed
+ * either a probepoint or a debugger breakpoint
+ * at this address. In either case, no further
+ * handling of this interrupt is appropriate.
+ * Return back to original instruction, and continue.
+ */
+}
+
+static int __kprobes
+kprobe_ss_hit(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ if ((kcb->ss_ctx.ss_pending)
+ && (kcb->ss_ctx.match_addr == addr)) {
+ clear_ss_context(kcb); /* clear pending ss */
+ return DBG_HOOK_HANDLED;
+ }
+ /* not ours, kprobes should ignore it */
+ return DBG_HOOK_ERROR;
+}
+
+int __kprobes
+kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ int retval;
+
+ /* return error if this is not our step */
+ retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
+
+ if (retval == DBG_HOOK_HANDLED) {
+ kprobes_restore_local_irqflag(kcb, regs);
+ kernel_disable_single_step();
+
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 1);
+
+ post_kprobe_handler(kcb, regs);
+ }
+
+ return retval;
+}
+
+int __kprobes
+kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
+{
+ kprobe_handler(regs);
+ return DBG_HOOK_HANDLED;
+}
+
+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_ptr = kernel_stack_pointer(regs);
+
+ kcb->jprobe_saved_regs = *regs;
+ /*
+ * As Linus pointed out, gcc assumes that the callee
+ * owns the argument space and could overwrite it, e.g.
+ * tailcall optimization. So, to be absolutely safe
+ * we also save and restore enough stack bytes to cover
+ * the argument area.
+ */
+ memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+ MIN_STACK_SIZE(stack_ptr));
+
+ instruction_pointer_set(regs, (unsigned long) jp->entry);
+ preempt_disable();
+ pause_graph_tracing();
+ return 1;
+}
+
+void __kprobes jprobe_return(void)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ /*
+ * Jprobe handler return by entering break exception,
+ * encoded same as kprobe, but with following conditions
+ * -a magic number in x0 to identify from rest of other kprobes.
+ * -restore stack addr to original saved pt_regs
+ */
+ asm volatile ("ldr x0, [%0]\n\t"
+ "mov sp, x0\n\t"
+ ".globl jprobe_return_break\n\t"
+ "jprobe_return_break:\n\t"
+ "brk %1\n\t"
+ :
+ : "r"(&kcb->jprobe_saved_regs.sp),
+ "I"(BRK64_ESR_KPROBES)
+ : "memory");
+}
+
+int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_addr = kcb->jprobe_saved_regs.sp;
+ long orig_sp = kernel_stack_pointer(regs);
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+
+ if (instruction_pointer(regs) != (u64) jprobe_return_break)
+ return 0;
+
+ if (orig_sp != stack_addr) {
+ struct pt_regs *saved_regs =
+ (struct pt_regs *)kcb->jprobe_saved_regs.sp;
+ pr_err("current sp %lx does not match saved sp %lx\n",
+ orig_sp, stack_addr);
+ pr_err("Saved registers for jprobe %p\n", jp);
+ show_regs(saved_regs);
+ pr_err("Current registers\n");
+ show_regs(regs);
+ BUG();
+ }
+ unpause_graph_tracing();
+ *regs = kcb->jprobe_saved_regs;
+ memcpy((void *)stack_addr, kcb->jprobes_stack,
+ MIN_STACK_SIZE(stack_addr));
+ preempt_enable_no_resched();
+ return 1;
+}
+
+int __init arch_init_kprobes(void)
+{
+ return 0;
+}
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 435e820..075ce32 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -121,6 +121,7 @@ SECTIONS
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
+ KPROBES_TEXT
HYPERVISOR_TEXT
IDMAP_TEXT
HIBERNATE_TEXT
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 013e2cb..2408e51 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -41,6 +41,28 @@
static const char *fault_name(unsigned int esr);
+#ifdef CONFIG_KPROBES
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+ int ret = 0;
+
+ /* kprobe_running() needs smp_processor_id() */
+ if (!user_mode(regs)) {
+ preempt_disable();
+ if (kprobe_running() && kprobe_fault_handler(regs, esr))
+ ret = 1;
+ preempt_enable();
+ }
+
+ return ret;
+}
+#else
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+ return 0;
+}
+#endif
+
/*
* Dump out the page tables associated with 'addr' in mm 'mm'.
*/
@@ -259,6 +281,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
unsigned long vm_flags = VM_READ | VM_WRITE | VM_EXEC;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ if (notify_page_fault(regs, esr))
+ return 0;
+
tsk = current;
mm = tsk->mm;
@@ -629,6 +654,7 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
return rv;
}
+NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
void cpu_enable_pan(void *__unused)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 05/10] arm64: Blacklist non-kprobe-able symbol
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Pratyush Anand <panand@redhat.com>
Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/kernel/arm64ksyms.c | 2 ++
arch/arm64/kernel/debug-monitors.c | 17 +++++++++++++++++
arch/arm64/kernel/hw_breakpoint.c | 8 ++++++++
arch/arm64/kernel/kgdb.c | 4 ++++
4 files changed, 31 insertions(+)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 678f30b0..b96ff1a 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -27,6 +27,7 @@
#include <linux/uaccess.h>
#include <linux/io.h>
#include <linux/arm-smccc.h>
+#include <linux/kprobes.h>
#include <asm/checksum.h>
@@ -68,6 +69,7 @@ EXPORT_SYMBOL(test_and_change_bit);
#ifdef CONFIG_FUNCTION_TRACER
EXPORT_SYMBOL(_mcount);
+NOKPROBE_SYMBOL(_mcount);
#endif
/* arm-smccc */
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 395de61..2fbc1b9 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -49,6 +49,7 @@ static void mdscr_write(u32 mdscr)
asm volatile("msr mdscr_el1, %0" :: "r" (mdscr));
local_dbg_restore(flags);
}
+NOKPROBE_SYMBOL(mdscr_write);
static u32 mdscr_read(void)
{
@@ -56,6 +57,7 @@ static u32 mdscr_read(void)
asm volatile("mrs %0, mdscr_el1" : "=r" (mdscr));
return mdscr;
}
+NOKPROBE_SYMBOL(mdscr_read);
/*
* Allow root to disable self-hosted debug from userspace.
@@ -104,6 +106,7 @@ void enable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(enable_debug_monitors);
void disable_debug_monitors(enum dbg_active_el el)
{
@@ -124,6 +127,7 @@ void disable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(disable_debug_monitors);
/*
* OS lock clearing.
@@ -174,6 +178,7 @@ static void set_regs_spsr_ss(struct pt_regs *regs)
spsr |= DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(set_regs_spsr_ss);
static void clear_regs_spsr_ss(struct pt_regs *regs)
{
@@ -183,6 +188,7 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
spsr &= ~DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(clear_regs_spsr_ss);
/* EL1 Single Step Handler hooks */
static LIST_HEAD(step_hook);
@@ -226,6 +232,7 @@ static int call_step_hook(struct pt_regs *regs, unsigned int esr)
return retval;
}
+NOKPROBE_SYMBOL(call_step_hook);
static void send_user_sigtrap(int si_code)
{
@@ -284,6 +291,7 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
return 0;
}
+NOKPROBE_SYMBOL(single_step_handler);
/*
* Breakpoint handler is re-entrant as another breakpoint can
@@ -321,6 +329,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned int esr)
return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
}
+NOKPROBE_SYMBOL(call_break_hook);
static int brk_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -341,6 +350,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
return 0;
}
+NOKPROBE_SYMBOL(brk_handler);
int aarch32_break_handler(struct pt_regs *regs)
{
@@ -377,6 +387,7 @@ int aarch32_break_handler(struct pt_regs *regs)
send_user_sigtrap(TRAP_BRKPT);
return 0;
}
+NOKPROBE_SYMBOL(aarch32_break_handler);
static int __init debug_traps_init(void)
{
@@ -398,6 +409,7 @@ void user_rewind_single_step(struct task_struct *task)
if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_rewind_single_step);
void user_fastforward_single_step(struct task_struct *task)
{
@@ -413,6 +425,7 @@ void kernel_enable_single_step(struct pt_regs *regs)
mdscr_write(mdscr_read() | DBG_MDSCR_SS);
enable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_enable_single_step);
void kernel_disable_single_step(void)
{
@@ -420,12 +433,14 @@ void kernel_disable_single_step(void)
mdscr_write(mdscr_read() & ~DBG_MDSCR_SS);
disable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_disable_single_step);
int kernel_active_single_step(void)
{
WARN_ON(!irqs_disabled());
return mdscr_read() & DBG_MDSCR_SS;
}
+NOKPROBE_SYMBOL(kernel_active_single_step);
/* ptrace API */
void user_enable_single_step(struct task_struct *task)
@@ -433,8 +448,10 @@ void user_enable_single_step(struct task_struct *task)
set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_enable_single_step);
void user_disable_single_step(struct task_struct *task)
{
clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
}
+NOKPROBE_SYMBOL(user_disable_single_step);
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index ce21aa8..26a6bf7 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -24,6 +24,7 @@
#include <linux/cpu_pm.h>
#include <linux/errno.h>
#include <linux/hw_breakpoint.h>
+#include <linux/kprobes.h>
#include <linux/perf_event.h>
#include <linux/ptrace.h>
#include <linux/smp.h>
@@ -127,6 +128,7 @@ static u64 read_wb_reg(int reg, int n)
return val;
}
+NOKPROBE_SYMBOL(read_wb_reg);
static void write_wb_reg(int reg, int n, u64 val)
{
@@ -140,6 +142,7 @@ static void write_wb_reg(int reg, int n, u64 val)
}
isb();
}
+NOKPROBE_SYMBOL(write_wb_reg);
/*
* Convert a breakpoint privilege level to the corresponding exception
@@ -157,6 +160,7 @@ static enum dbg_active_el debug_exception_level(int privilege)
return -EINVAL;
}
}
+NOKPROBE_SYMBOL(debug_exception_level);
enum hw_breakpoint_ops {
HW_BREAKPOINT_INSTALL,
@@ -575,6 +579,7 @@ static void toggle_bp_registers(int reg, enum dbg_active_el el, int enable)
write_wb_reg(reg, i, ctrl);
}
}
+NOKPROBE_SYMBOL(toggle_bp_registers);
/*
* Debug exception handlers.
@@ -654,6 +659,7 @@ unlock:
return 0;
}
+NOKPROBE_SYMBOL(breakpoint_handler);
static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -756,6 +762,7 @@ unlock:
return 0;
}
+NOKPROBE_SYMBOL(watchpoint_handler);
/*
* Handle single-step exception.
@@ -813,6 +820,7 @@ int reinstall_suspended_bps(struct pt_regs *regs)
return !handled_exception;
}
+NOKPROBE_SYMBOL(reinstall_suspended_bps);
/*
* Context-switcher for restoring suspended breakpoints.
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index b5f063e..8c57f64 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -22,6 +22,7 @@
#include <linux/irq.h>
#include <linux/kdebug.h>
#include <linux/kgdb.h>
+#include <linux/kprobes.h>
#include <asm/traps.h>
struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
@@ -230,6 +231,7 @@ static int kgdb_brk_fn(struct pt_regs *regs, unsigned int esr)
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
+NOKPROBE_SYMBOL(kgdb_brk_fn)
static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
{
@@ -238,12 +240,14 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
return 0;
}
+NOKPROBE_SYMBOL(kgdb_compiled_brk_fn);
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
+NOKPROBE_SYMBOL(kgdb_step_brk_fn);
static struct break_hook kgdb_brkpt_hook = {
.esr_mask = 0xffffffff,
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 05/10] arm64: Blacklist non-kprobe-able symbol
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Pratyush Anand <panand@redhat.com>
Add all function symbols which are called from do_debug_exception under
NOKPROBE_SYMBOL, as they can not kprobed.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/kernel/arm64ksyms.c | 2 ++
arch/arm64/kernel/debug-monitors.c | 17 +++++++++++++++++
arch/arm64/kernel/hw_breakpoint.c | 8 ++++++++
arch/arm64/kernel/kgdb.c | 4 ++++
4 files changed, 31 insertions(+)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 678f30b0..b96ff1a 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -27,6 +27,7 @@
#include <linux/uaccess.h>
#include <linux/io.h>
#include <linux/arm-smccc.h>
+#include <linux/kprobes.h>
#include <asm/checksum.h>
@@ -68,6 +69,7 @@ EXPORT_SYMBOL(test_and_change_bit);
#ifdef CONFIG_FUNCTION_TRACER
EXPORT_SYMBOL(_mcount);
+NOKPROBE_SYMBOL(_mcount);
#endif
/* arm-smccc */
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 395de61..2fbc1b9 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -49,6 +49,7 @@ static void mdscr_write(u32 mdscr)
asm volatile("msr mdscr_el1, %0" :: "r" (mdscr));
local_dbg_restore(flags);
}
+NOKPROBE_SYMBOL(mdscr_write);
static u32 mdscr_read(void)
{
@@ -56,6 +57,7 @@ static u32 mdscr_read(void)
asm volatile("mrs %0, mdscr_el1" : "=r" (mdscr));
return mdscr;
}
+NOKPROBE_SYMBOL(mdscr_read);
/*
* Allow root to disable self-hosted debug from userspace.
@@ -104,6 +106,7 @@ void enable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(enable_debug_monitors);
void disable_debug_monitors(enum dbg_active_el el)
{
@@ -124,6 +127,7 @@ void disable_debug_monitors(enum dbg_active_el el)
mdscr_write(mdscr);
}
}
+NOKPROBE_SYMBOL(disable_debug_monitors);
/*
* OS lock clearing.
@@ -174,6 +178,7 @@ static void set_regs_spsr_ss(struct pt_regs *regs)
spsr |= DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(set_regs_spsr_ss);
static void clear_regs_spsr_ss(struct pt_regs *regs)
{
@@ -183,6 +188,7 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
spsr &= ~DBG_SPSR_SS;
regs->pstate = spsr;
}
+NOKPROBE_SYMBOL(clear_regs_spsr_ss);
/* EL1 Single Step Handler hooks */
static LIST_HEAD(step_hook);
@@ -226,6 +232,7 @@ static int call_step_hook(struct pt_regs *regs, unsigned int esr)
return retval;
}
+NOKPROBE_SYMBOL(call_step_hook);
static void send_user_sigtrap(int si_code)
{
@@ -284,6 +291,7 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
return 0;
}
+NOKPROBE_SYMBOL(single_step_handler);
/*
* Breakpoint handler is re-entrant as another breakpoint can
@@ -321,6 +329,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned int esr)
return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
}
+NOKPROBE_SYMBOL(call_break_hook);
static int brk_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -341,6 +350,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
return 0;
}
+NOKPROBE_SYMBOL(brk_handler);
int aarch32_break_handler(struct pt_regs *regs)
{
@@ -377,6 +387,7 @@ int aarch32_break_handler(struct pt_regs *regs)
send_user_sigtrap(TRAP_BRKPT);
return 0;
}
+NOKPROBE_SYMBOL(aarch32_break_handler);
static int __init debug_traps_init(void)
{
@@ -398,6 +409,7 @@ void user_rewind_single_step(struct task_struct *task)
if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_rewind_single_step);
void user_fastforward_single_step(struct task_struct *task)
{
@@ -413,6 +425,7 @@ void kernel_enable_single_step(struct pt_regs *regs)
mdscr_write(mdscr_read() | DBG_MDSCR_SS);
enable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_enable_single_step);
void kernel_disable_single_step(void)
{
@@ -420,12 +433,14 @@ void kernel_disable_single_step(void)
mdscr_write(mdscr_read() & ~DBG_MDSCR_SS);
disable_debug_monitors(DBG_ACTIVE_EL1);
}
+NOKPROBE_SYMBOL(kernel_disable_single_step);
int kernel_active_single_step(void)
{
WARN_ON(!irqs_disabled());
return mdscr_read() & DBG_MDSCR_SS;
}
+NOKPROBE_SYMBOL(kernel_active_single_step);
/* ptrace API */
void user_enable_single_step(struct task_struct *task)
@@ -433,8 +448,10 @@ void user_enable_single_step(struct task_struct *task)
set_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
set_regs_spsr_ss(task_pt_regs(task));
}
+NOKPROBE_SYMBOL(user_enable_single_step);
void user_disable_single_step(struct task_struct *task)
{
clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
}
+NOKPROBE_SYMBOL(user_disable_single_step);
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index ce21aa8..26a6bf7 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -24,6 +24,7 @@
#include <linux/cpu_pm.h>
#include <linux/errno.h>
#include <linux/hw_breakpoint.h>
+#include <linux/kprobes.h>
#include <linux/perf_event.h>
#include <linux/ptrace.h>
#include <linux/smp.h>
@@ -127,6 +128,7 @@ static u64 read_wb_reg(int reg, int n)
return val;
}
+NOKPROBE_SYMBOL(read_wb_reg);
static void write_wb_reg(int reg, int n, u64 val)
{
@@ -140,6 +142,7 @@ static void write_wb_reg(int reg, int n, u64 val)
}
isb();
}
+NOKPROBE_SYMBOL(write_wb_reg);
/*
* Convert a breakpoint privilege level to the corresponding exception
@@ -157,6 +160,7 @@ static enum dbg_active_el debug_exception_level(int privilege)
return -EINVAL;
}
}
+NOKPROBE_SYMBOL(debug_exception_level);
enum hw_breakpoint_ops {
HW_BREAKPOINT_INSTALL,
@@ -575,6 +579,7 @@ static void toggle_bp_registers(int reg, enum dbg_active_el el, int enable)
write_wb_reg(reg, i, ctrl);
}
}
+NOKPROBE_SYMBOL(toggle_bp_registers);
/*
* Debug exception handlers.
@@ -654,6 +659,7 @@ unlock:
return 0;
}
+NOKPROBE_SYMBOL(breakpoint_handler);
static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
@@ -756,6 +762,7 @@ unlock:
return 0;
}
+NOKPROBE_SYMBOL(watchpoint_handler);
/*
* Handle single-step exception.
@@ -813,6 +820,7 @@ int reinstall_suspended_bps(struct pt_regs *regs)
return !handled_exception;
}
+NOKPROBE_SYMBOL(reinstall_suspended_bps);
/*
* Context-switcher for restoring suspended breakpoints.
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index b5f063e..8c57f64 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -22,6 +22,7 @@
#include <linux/irq.h>
#include <linux/kdebug.h>
#include <linux/kgdb.h>
+#include <linux/kprobes.h>
#include <asm/traps.h>
struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
@@ -230,6 +231,7 @@ static int kgdb_brk_fn(struct pt_regs *regs, unsigned int esr)
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
+NOKPROBE_SYMBOL(kgdb_brk_fn)
static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
{
@@ -238,12 +240,14 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int esr)
return 0;
}
+NOKPROBE_SYMBOL(kgdb_compiled_brk_fn);
static int kgdb_step_brk_fn(struct pt_regs *regs, unsigned int esr)
{
kgdb_handle_exception(1, SIGTRAP, 0, regs);
return 0;
}
+NOKPROBE_SYMBOL(kgdb_step_brk_fn);
static struct break_hook kgdb_brkpt_hook = {
.esr_mask = 0xffffffff,
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Pratyush Anand <panand@redhat.com>
Entry symbols are not kprobe safe. So blacklist them for kprobing.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/kernel/entry.S | 3 +++
arch/arm64/kernel/probes/kprobes.c | 26 ++++++++++++++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
3 files changed, 30 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 12e8d2b..7d99bed 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
* Exception vectors.
*/
+ .pushsection ".entry.text", "ax"
.align 11
ENTRY(vectors)
ventry el1_sync_invalid // Synchronous EL1t
@@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b sys_rt_sigreturn
ENDPROC(sys_rt_sigreturn_wrapper)
+
+ .popsection
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 4496801..0fe2b65 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -30,6 +30,7 @@
#include <asm/insn.h>
#include <asm/uaccess.h>
#include <asm/irq.h>
+#include <asm-generic/sections.h>
#include "decode-insn.h"
@@ -519,6 +520,31 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
return 1;
}
+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+ extern char __idmap_text_start[], __idmap_text_end[];
+ extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+ if ((addr >= (unsigned long)__kprobes_text_start &&
+ addr < (unsigned long)__kprobes_text_end) ||
+ (addr >= (unsigned long)__entry_text_start &&
+ addr < (unsigned long)__entry_text_end) ||
+ (addr >= (unsigned long)__idmap_text_start &&
+ addr < (unsigned long)__idmap_text_end) ||
+ !!search_exception_tables(addr))
+ return true;
+
+ if (!is_kernel_in_hyp_mode()) {
+ if ((addr >= (unsigned long)__hyp_text_start &&
+ addr < (unsigned long)__hyp_text_end) ||
+ (addr >= (unsigned long)__hyp_idmap_text_start &&
+ addr < (unsigned long)__hyp_idmap_text_end))
+ return true;
+ }
+
+ return false;
+}
+
int __init arch_init_kprobes(void)
{
return 0;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 075ce32..9f59394 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -118,6 +118,7 @@ SECTIONS
__exception_text_end = .;
IRQENTRY_TEXT
SOFTIRQENTRY_TEXT
+ ENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Pratyush Anand <panand@redhat.com>
Entry symbols are not kprobe safe. So blacklist them for kprobing.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/kernel/entry.S | 3 +++
arch/arm64/kernel/probes/kprobes.c | 26 ++++++++++++++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
3 files changed, 30 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 12e8d2b..7d99bed 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
* Exception vectors.
*/
+ .pushsection ".entry.text", "ax"
.align 11
ENTRY(vectors)
ventry el1_sync_invalid // Synchronous EL1t
@@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
mov x0, sp
b sys_rt_sigreturn
ENDPROC(sys_rt_sigreturn_wrapper)
+
+ .popsection
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 4496801..0fe2b65 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -30,6 +30,7 @@
#include <asm/insn.h>
#include <asm/uaccess.h>
#include <asm/irq.h>
+#include <asm-generic/sections.h>
#include "decode-insn.h"
@@ -519,6 +520,31 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
return 1;
}
+bool arch_within_kprobe_blacklist(unsigned long addr)
+{
+ extern char __idmap_text_start[], __idmap_text_end[];
+ extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+ if ((addr >= (unsigned long)__kprobes_text_start &&
+ addr < (unsigned long)__kprobes_text_end) ||
+ (addr >= (unsigned long)__entry_text_start &&
+ addr < (unsigned long)__entry_text_end) ||
+ (addr >= (unsigned long)__idmap_text_start &&
+ addr < (unsigned long)__idmap_text_end) ||
+ !!search_exception_tables(addr))
+ return true;
+
+ if (!is_kernel_in_hyp_mode()) {
+ if ((addr >= (unsigned long)__hyp_text_start &&
+ addr < (unsigned long)__hyp_text_end) ||
+ (addr >= (unsigned long)__hyp_idmap_text_start &&
+ addr < (unsigned long)__hyp_idmap_text_end))
+ return true;
+ }
+
+ return false;
+}
+
int __init arch_init_kprobes(void)
{
return 0;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 075ce32..9f59394 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -118,6 +118,7 @@ SECTIONS
__exception_text_end = .;
IRQENTRY_TEXT
SOFTIRQENTRY_TEXT
+ ENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 07/10] arm64: kprobes instruction simulation support
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Kprobes needs simulation of instructions that cannot be stepped
from a different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.
The following instruction categories are simulated:
- All branching instructions(conditional, register, and immediate)
- Literal access instructions(load-literal, adr/adrp)
Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP.
Thanks to Will Cohen for assorted suggested changes.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: William Cohen <wcohen@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/probes.h | 5 +-
arch/arm64/kernel/insn.c | 1 +
arch/arm64/kernel/probes/Makefile | 3 +-
arch/arm64/kernel/probes/decode-insn.c | 33 ++++-
arch/arm64/kernel/probes/decode-insn.h | 1 +
arch/arm64/kernel/probes/kprobes.c | 53 ++++++--
arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++++++++++++++++++++++++
arch/arm64/kernel/probes/simulate-insn.h | 28 ++++
8 files changed, 327 insertions(+), 15 deletions(-)
create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index 1e8a21a..5af574d 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -15,17 +15,18 @@
#ifndef _ARM_PROBES_H
#define _ARM_PROBES_H
+#include <asm/opcodes.h>
+
struct kprobe;
struct arch_specific_insn;
typedef u32 kprobe_opcode_t;
-typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
/* architecture specific copy of original instruction */
struct arch_specific_insn {
kprobe_opcode_t *insn;
- kprobes_pstate_check_t *pstate_cc;
+ pstate_check_t *pstate_cc;
kprobes_handler_t *handler;
/* restore address after step xol */
unsigned long restore;
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 5cb2f3d..63f9432 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -30,6 +30,7 @@
#include <asm/cacheflush.h>
#include <asm/debug-monitors.h>
#include <asm/fixmap.h>
+#include <asm/opcodes.h>
#include <asm/insn.h>
#define AARCH64_INSN_SF_BIT BIT(31)
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
index bc159bf..e184d00 100644
--- a/arch/arm64/kernel/probes/Makefile
+++ b/arch/arm64/kernel/probes/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o
+obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
+ simulate-insn.o
diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
index 95c0c52..37e47a9 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -21,6 +21,7 @@
#include <asm/sections.h>
#include "decode-insn.h"
+#include "simulate-insn.h"
static bool __kprobes aarch64_insn_is_steppable(u32 insn)
{
@@ -74,6 +75,7 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn)
/* Return:
* INSN_REJECTED If instruction is one not allowed to kprobe,
* INSN_GOOD If instruction is supported and uses instruction slot,
+ * INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
*/
static enum kprobe_insn __kprobes
arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
@@ -84,8 +86,37 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
*/
if (aarch64_insn_is_steppable(insn))
return INSN_GOOD;
- else
+
+ if (aarch64_insn_is_bcond(insn)) {
+ asi->handler = simulate_b_cond;
+ } else if (aarch64_insn_is_cbz(insn) ||
+ aarch64_insn_is_cbnz(insn)) {
+ asi->handler = simulate_cbz_cbnz;
+ } else if (aarch64_insn_is_tbz(insn) ||
+ aarch64_insn_is_tbnz(insn)) {
+ asi->handler = simulate_tbz_tbnz;
+ } else if (aarch64_insn_is_adr_adrp(insn)) {
+ asi->handler = simulate_adr_adrp;
+ } else if (aarch64_insn_is_b(insn) ||
+ aarch64_insn_is_bl(insn)) {
+ asi->handler = simulate_b_bl;
+ } else if (aarch64_insn_is_br(insn) ||
+ aarch64_insn_is_blr(insn) ||
+ aarch64_insn_is_ret(insn)) {
+ asi->handler = simulate_br_blr_ret;
+ } else if (aarch64_insn_is_ldr_lit(insn)) {
+ asi->handler = simulate_ldr_literal;
+ } else if (aarch64_insn_is_ldrsw_lit(insn)) {
+ asi->handler = simulate_ldrsw_literal;
+ } else {
+ /*
+ * Instruction cannot be stepped out-of-line and we don't
+ * (yet) simulate it.
+ */
return INSN_REJECTED;
+ }
+
+ return INSN_GOOD_NO_SLOT;
}
static bool __kprobes
diff --git a/arch/arm64/kernel/probes/decode-insn.h b/arch/arm64/kernel/probes/decode-insn.h
index ad5ba9c..d438289 100644
--- a/arch/arm64/kernel/probes/decode-insn.h
+++ b/arch/arm64/kernel/probes/decode-insn.h
@@ -25,6 +25,7 @@
enum kprobe_insn {
INSN_REJECTED,
+ INSN_GOOD_NO_SLOT,
INSN_GOOD,
};
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 0fe2b65..63eb0a1 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -45,6 +45,9 @@ void jprobe_return_break(void);
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -61,6 +64,23 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
sizeof(kprobe_opcode_t);
}
+static void __kprobes arch_prepare_simulate(struct kprobe *p)
+{
+ /* This instructions is not executed xol. No need to adjust the PC */
+ p->ainsn.restore = 0;
+}
+
+static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ if (p->ainsn.handler)
+ p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
+
+ /* single step simulated, now go for post processing */
+ post_kprobe_handler(kcb, regs);
+}
+
int __kprobes arch_prepare_kprobe(struct kprobe *p)
{
unsigned long probe_addr = (unsigned long)p->addr;
@@ -84,6 +104,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
case INSN_REJECTED: /* insn not supported */
return -EINVAL;
+ case INSN_GOOD_NO_SLOT: /* insn need simulation */
+ p->ainsn.insn = NULL;
+ break;
+
case INSN_GOOD: /* instruction uses slot */
p->ainsn.insn = get_insn_slot();
if (!p->ainsn.insn)
@@ -92,7 +116,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
};
/* prepare the instruction */
- arch_prepare_ss_slot(p);
+ if (p->ainsn.insn)
+ arch_prepare_ss_slot(p);
+ else
+ arch_prepare_simulate(p);
return 0;
}
@@ -218,20 +245,24 @@ static void __kprobes setup_singlestep(struct kprobe *p,
kcb->kprobe_status = KPROBE_HIT_SS;
}
- BUG_ON(!p->ainsn.insn);
- /* prepare for single stepping */
- slot = (unsigned long)p->ainsn.insn;
+ if (p->ainsn.insn) {
+ /* prepare for single stepping */
+ slot = (unsigned long)p->ainsn.insn;
- set_ss_context(kcb, slot); /* mark pending ss */
+ set_ss_context(kcb, slot); /* mark pending ss */
- if (kcb->kprobe_status == KPROBE_REENTER)
- spsr_set_debug_flag(regs, 0);
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 0);
- /* IRQs and single stepping do not mix well. */
- kprobes_save_local_irqflag(kcb, regs);
- kernel_enable_single_step(regs);
- instruction_pointer_set(regs, slot);
+ /* IRQs and single stepping do not mix well. */
+ kprobes_save_local_irqflag(kcb, regs);
+ kernel_enable_single_step(regs);
+ instruction_pointer_set(regs, slot);
+ } else {
+ /* insn simulation */
+ arch_simulate_insn(p, regs);
+ }
}
static int __kprobes reenter_kprobe(struct kprobe *p,
diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/probes/simulate-insn.c
new file mode 100644
index 0000000..429c333
--- /dev/null
+++ b/arch/arm64/kernel/probes/simulate-insn.c
@@ -0,0 +1,218 @@
+/*
+ * arch/arm64/kernel/probes/simulate-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+
+#include "simulate-insn.h"
+
+#define sign_extend(x, signbit) \
+ ((x) | (0 - ((x) & (1 << (signbit)))))
+
+#define bbl_displacement(insn) \
+ sign_extend(((insn) & 0x3ffffff) << 2, 27)
+
+#define bcond_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define cbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define tbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
+
+#define ldr_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+static inline void set_x_reg(struct pt_regs *regs, int reg, u64 val)
+{
+ if (reg < 31)
+ regs->regs[reg] = val;
+}
+
+static inline void set_w_reg(struct pt_regs *regs, int reg, u64 val)
+{
+ if (reg < 31)
+ regs->regs[reg] = lower_32_bits(val);
+}
+
+static inline u64 get_x_reg(struct pt_regs *regs, int reg)
+{
+ if (reg < 31)
+ return regs->regs[reg];
+ else
+ return 0;
+}
+
+static inline u32 get_w_reg(struct pt_regs *regs, int reg)
+{
+ if (reg < 31)
+ return lower_32_bits(regs->regs[reg]);
+ else
+ return 0;
+}
+
+static bool __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ (get_x_reg(regs, xn) == 0) : (get_w_reg(regs, xn) == 0);
+}
+
+static bool __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ (get_x_reg(regs, xn) != 0) : (get_w_reg(regs, xn) != 0);
+}
+
+static bool __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return ((get_x_reg(regs, xn) >> bit_pos) & 0x1) == 0;
+}
+
+static bool __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return ((get_x_reg(regs, xn) >> bit_pos) & 0x1) != 0;
+}
+
+/*
+ * instruction simulation functions
+ */
+void __kprobes
+simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
+{
+ long imm, xn, val;
+
+ xn = opcode & 0x1f;
+ imm = ((opcode >> 3) & 0x1ffffc) | ((opcode >> 29) & 0x3);
+ imm = sign_extend(imm, 20);
+ if (opcode & 0x80000000)
+ val = (imm<<12) + (addr & 0xfffffffffffff000);
+ else
+ val = imm + addr;
+
+ set_x_reg(regs, xn, val);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
+
+void __kprobes
+simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = bbl_displacement(opcode);
+
+ /* Link register is x30 */
+ if (opcode & (1 << 31))
+ set_x_reg(regs, 30, addr + 4);
+
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (aarch32_opcode_cond_checks[opcode & 0xf](regs->pstate & 0xffffffff))
+ disp = bcond_displacement(opcode);
+
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int xn = (opcode >> 5) & 0x1f;
+
+ /* update pc first in case we're doing a "blr lr" */
+ instruction_pointer_set(regs, get_x_reg(regs, xn));
+
+ /* Link register is x30 */
+ if (((opcode >> 21) & 0x3) == 1)
+ set_x_reg(regs, 30, addr + 4);
+}
+
+void __kprobes
+simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (opcode & (1 << 24)) {
+ if (check_cbnz(opcode, regs))
+ disp = cbz_displacement(opcode);
+ } else {
+ if (check_cbz(opcode, regs))
+ disp = cbz_displacement(opcode);
+ }
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (opcode & (1 << 24)) {
+ if (check_tbnz(opcode, regs))
+ disp = tbz_displacement(opcode);
+ } else {
+ if (check_tbz(opcode, regs))
+ disp = tbz_displacement(opcode);
+ }
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ u64 *load_addr;
+ int xn = opcode & 0x1f;
+ int disp;
+
+ disp = ldr_displacement(opcode);
+ load_addr = (u64 *) (addr + disp);
+
+ if (opcode & (1 << 30)) /* x0-x30 */
+ set_x_reg(regs, xn, *load_addr);
+ else /* w0-w30 */
+ set_w_reg(regs, xn, *load_addr);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
+
+void __kprobes
+simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ s32 *load_addr;
+ int xn = opcode & 0x1f;
+ int disp;
+
+ disp = ldr_displacement(opcode);
+ load_addr = (s32 *) (addr + disp);
+
+ set_x_reg(regs, xn, *load_addr);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
diff --git a/arch/arm64/kernel/probes/simulate-insn.h b/arch/arm64/kernel/probes/simulate-insn.h
new file mode 100644
index 0000000..050bde6
--- /dev/null
+++ b/arch/arm64/kernel/probes/simulate-insn.h
@@ -0,0 +1,28 @@
+/*
+ * arch/arm64/kernel/probes/simulate-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_SIMULATE_INSN_H
+#define _ARM_KERNEL_KPROBES_SIMULATE_INSN_H
+
+void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
+
+#endif /* _ARM_KERNEL_KPROBES_SIMULATE_INSN_H */
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 07/10] arm64: kprobes instruction simulation support
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Kprobes needs simulation of instructions that cannot be stepped
from a different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.
The following instruction categories are simulated:
- All branching instructions(conditional, register, and immediate)
- Literal access instructions(load-literal, adr/adrp)
Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP.
Thanks to Will Cohen for assorted suggested changes.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: William Cohen <wcohen@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/probes.h | 5 +-
arch/arm64/kernel/insn.c | 1 +
arch/arm64/kernel/probes/Makefile | 3 +-
arch/arm64/kernel/probes/decode-insn.c | 33 ++++-
arch/arm64/kernel/probes/decode-insn.h | 1 +
arch/arm64/kernel/probes/kprobes.c | 53 ++++++--
arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++++++++++++++++++++++++
arch/arm64/kernel/probes/simulate-insn.h | 28 ++++
8 files changed, 327 insertions(+), 15 deletions(-)
create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index 1e8a21a..5af574d 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -15,17 +15,18 @@
#ifndef _ARM_PROBES_H
#define _ARM_PROBES_H
+#include <asm/opcodes.h>
+
struct kprobe;
struct arch_specific_insn;
typedef u32 kprobe_opcode_t;
-typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
/* architecture specific copy of original instruction */
struct arch_specific_insn {
kprobe_opcode_t *insn;
- kprobes_pstate_check_t *pstate_cc;
+ pstate_check_t *pstate_cc;
kprobes_handler_t *handler;
/* restore address after step xol */
unsigned long restore;
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 5cb2f3d..63f9432 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -30,6 +30,7 @@
#include <asm/cacheflush.h>
#include <asm/debug-monitors.h>
#include <asm/fixmap.h>
+#include <asm/opcodes.h>
#include <asm/insn.h>
#define AARCH64_INSN_SF_BIT BIT(31)
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
index bc159bf..e184d00 100644
--- a/arch/arm64/kernel/probes/Makefile
+++ b/arch/arm64/kernel/probes/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o
+obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
+ simulate-insn.o
diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
index 95c0c52..37e47a9 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -21,6 +21,7 @@
#include <asm/sections.h>
#include "decode-insn.h"
+#include "simulate-insn.h"
static bool __kprobes aarch64_insn_is_steppable(u32 insn)
{
@@ -74,6 +75,7 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn)
/* Return:
* INSN_REJECTED If instruction is one not allowed to kprobe,
* INSN_GOOD If instruction is supported and uses instruction slot,
+ * INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
*/
static enum kprobe_insn __kprobes
arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
@@ -84,8 +86,37 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
*/
if (aarch64_insn_is_steppable(insn))
return INSN_GOOD;
- else
+
+ if (aarch64_insn_is_bcond(insn)) {
+ asi->handler = simulate_b_cond;
+ } else if (aarch64_insn_is_cbz(insn) ||
+ aarch64_insn_is_cbnz(insn)) {
+ asi->handler = simulate_cbz_cbnz;
+ } else if (aarch64_insn_is_tbz(insn) ||
+ aarch64_insn_is_tbnz(insn)) {
+ asi->handler = simulate_tbz_tbnz;
+ } else if (aarch64_insn_is_adr_adrp(insn)) {
+ asi->handler = simulate_adr_adrp;
+ } else if (aarch64_insn_is_b(insn) ||
+ aarch64_insn_is_bl(insn)) {
+ asi->handler = simulate_b_bl;
+ } else if (aarch64_insn_is_br(insn) ||
+ aarch64_insn_is_blr(insn) ||
+ aarch64_insn_is_ret(insn)) {
+ asi->handler = simulate_br_blr_ret;
+ } else if (aarch64_insn_is_ldr_lit(insn)) {
+ asi->handler = simulate_ldr_literal;
+ } else if (aarch64_insn_is_ldrsw_lit(insn)) {
+ asi->handler = simulate_ldrsw_literal;
+ } else {
+ /*
+ * Instruction cannot be stepped out-of-line and we don't
+ * (yet) simulate it.
+ */
return INSN_REJECTED;
+ }
+
+ return INSN_GOOD_NO_SLOT;
}
static bool __kprobes
diff --git a/arch/arm64/kernel/probes/decode-insn.h b/arch/arm64/kernel/probes/decode-insn.h
index ad5ba9c..d438289 100644
--- a/arch/arm64/kernel/probes/decode-insn.h
+++ b/arch/arm64/kernel/probes/decode-insn.h
@@ -25,6 +25,7 @@
enum kprobe_insn {
INSN_REJECTED,
+ INSN_GOOD_NO_SLOT,
INSN_GOOD,
};
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 0fe2b65..63eb0a1 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -45,6 +45,9 @@ void jprobe_return_break(void);
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -61,6 +64,23 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
sizeof(kprobe_opcode_t);
}
+static void __kprobes arch_prepare_simulate(struct kprobe *p)
+{
+ /* This instructions is not executed xol. No need to adjust the PC */
+ p->ainsn.restore = 0;
+}
+
+static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ if (p->ainsn.handler)
+ p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
+
+ /* single step simulated, now go for post processing */
+ post_kprobe_handler(kcb, regs);
+}
+
int __kprobes arch_prepare_kprobe(struct kprobe *p)
{
unsigned long probe_addr = (unsigned long)p->addr;
@@ -84,6 +104,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
case INSN_REJECTED: /* insn not supported */
return -EINVAL;
+ case INSN_GOOD_NO_SLOT: /* insn need simulation */
+ p->ainsn.insn = NULL;
+ break;
+
case INSN_GOOD: /* instruction uses slot */
p->ainsn.insn = get_insn_slot();
if (!p->ainsn.insn)
@@ -92,7 +116,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
};
/* prepare the instruction */
- arch_prepare_ss_slot(p);
+ if (p->ainsn.insn)
+ arch_prepare_ss_slot(p);
+ else
+ arch_prepare_simulate(p);
return 0;
}
@@ -218,20 +245,24 @@ static void __kprobes setup_singlestep(struct kprobe *p,
kcb->kprobe_status = KPROBE_HIT_SS;
}
- BUG_ON(!p->ainsn.insn);
- /* prepare for single stepping */
- slot = (unsigned long)p->ainsn.insn;
+ if (p->ainsn.insn) {
+ /* prepare for single stepping */
+ slot = (unsigned long)p->ainsn.insn;
- set_ss_context(kcb, slot); /* mark pending ss */
+ set_ss_context(kcb, slot); /* mark pending ss */
- if (kcb->kprobe_status == KPROBE_REENTER)
- spsr_set_debug_flag(regs, 0);
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ spsr_set_debug_flag(regs, 0);
- /* IRQs and single stepping do not mix well. */
- kprobes_save_local_irqflag(kcb, regs);
- kernel_enable_single_step(regs);
- instruction_pointer_set(regs, slot);
+ /* IRQs and single stepping do not mix well. */
+ kprobes_save_local_irqflag(kcb, regs);
+ kernel_enable_single_step(regs);
+ instruction_pointer_set(regs, slot);
+ } else {
+ /* insn simulation */
+ arch_simulate_insn(p, regs);
+ }
}
static int __kprobes reenter_kprobe(struct kprobe *p,
diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/probes/simulate-insn.c
new file mode 100644
index 0000000..429c333
--- /dev/null
+++ b/arch/arm64/kernel/probes/simulate-insn.c
@@ -0,0 +1,218 @@
+/*
+ * arch/arm64/kernel/probes/simulate-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+
+#include "simulate-insn.h"
+
+#define sign_extend(x, signbit) \
+ ((x) | (0 - ((x) & (1 << (signbit)))))
+
+#define bbl_displacement(insn) \
+ sign_extend(((insn) & 0x3ffffff) << 2, 27)
+
+#define bcond_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define cbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define tbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
+
+#define ldr_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+static inline void set_x_reg(struct pt_regs *regs, int reg, u64 val)
+{
+ if (reg < 31)
+ regs->regs[reg] = val;
+}
+
+static inline void set_w_reg(struct pt_regs *regs, int reg, u64 val)
+{
+ if (reg < 31)
+ regs->regs[reg] = lower_32_bits(val);
+}
+
+static inline u64 get_x_reg(struct pt_regs *regs, int reg)
+{
+ if (reg < 31)
+ return regs->regs[reg];
+ else
+ return 0;
+}
+
+static inline u32 get_w_reg(struct pt_regs *regs, int reg)
+{
+ if (reg < 31)
+ return lower_32_bits(regs->regs[reg]);
+ else
+ return 0;
+}
+
+static bool __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ (get_x_reg(regs, xn) == 0) : (get_w_reg(regs, xn) == 0);
+}
+
+static bool __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ (get_x_reg(regs, xn) != 0) : (get_w_reg(regs, xn) != 0);
+}
+
+static bool __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return ((get_x_reg(regs, xn) >> bit_pos) & 0x1) == 0;
+}
+
+static bool __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return ((get_x_reg(regs, xn) >> bit_pos) & 0x1) != 0;
+}
+
+/*
+ * instruction simulation functions
+ */
+void __kprobes
+simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
+{
+ long imm, xn, val;
+
+ xn = opcode & 0x1f;
+ imm = ((opcode >> 3) & 0x1ffffc) | ((opcode >> 29) & 0x3);
+ imm = sign_extend(imm, 20);
+ if (opcode & 0x80000000)
+ val = (imm<<12) + (addr & 0xfffffffffffff000);
+ else
+ val = imm + addr;
+
+ set_x_reg(regs, xn, val);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
+
+void __kprobes
+simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = bbl_displacement(opcode);
+
+ /* Link register is x30 */
+ if (opcode & (1 << 31))
+ set_x_reg(regs, 30, addr + 4);
+
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (aarch32_opcode_cond_checks[opcode & 0xf](regs->pstate & 0xffffffff))
+ disp = bcond_displacement(opcode);
+
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int xn = (opcode >> 5) & 0x1f;
+
+ /* update pc first in case we're doing a "blr lr" */
+ instruction_pointer_set(regs, get_x_reg(regs, xn));
+
+ /* Link register is x30 */
+ if (((opcode >> 21) & 0x3) == 1)
+ set_x_reg(regs, 30, addr + 4);
+}
+
+void __kprobes
+simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (opcode & (1 << 24)) {
+ if (check_cbnz(opcode, regs))
+ disp = cbz_displacement(opcode);
+ } else {
+ if (check_cbz(opcode, regs))
+ disp = cbz_displacement(opcode);
+ }
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = 4;
+
+ if (opcode & (1 << 24)) {
+ if (check_tbnz(opcode, regs))
+ disp = tbz_displacement(opcode);
+ } else {
+ if (check_tbz(opcode, regs))
+ disp = tbz_displacement(opcode);
+ }
+ instruction_pointer_set(regs, addr + disp);
+}
+
+void __kprobes
+simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ u64 *load_addr;
+ int xn = opcode & 0x1f;
+ int disp;
+
+ disp = ldr_displacement(opcode);
+ load_addr = (u64 *) (addr + disp);
+
+ if (opcode & (1 << 30)) /* x0-x30 */
+ set_x_reg(regs, xn, *load_addr);
+ else /* w0-w30 */
+ set_w_reg(regs, xn, *load_addr);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
+
+void __kprobes
+simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ s32 *load_addr;
+ int xn = opcode & 0x1f;
+ int disp;
+
+ disp = ldr_displacement(opcode);
+ load_addr = (s32 *) (addr + disp);
+
+ set_x_reg(regs, xn, *load_addr);
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+}
diff --git a/arch/arm64/kernel/probes/simulate-insn.h b/arch/arm64/kernel/probes/simulate-insn.h
new file mode 100644
index 0000000..050bde6
--- /dev/null
+++ b/arch/arm64/kernel/probes/simulate-insn.h
@@ -0,0 +1,28 @@
+/*
+ * arch/arm64/kernel/probes/simulate-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_SIMULATE_INSN_H
+#define _ARM_KERNEL_KPROBES_SIMULATE_INSN_H
+
+void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
+
+#endif /* _ARM_KERNEL_KPROBES_SIMULATE_INSN_H */
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: William Cohen <wcohen@redhat.com>
The trampoline code is used by kretprobes to capture a return from a probed
function. This is done by saving the registers, calling the handler, and
restoring the registers. The code then returns to the original saved caller
return address. It is necessary to do this directly instead of using a
software breakpoint because the code used in processing that breakpoint
could itself be kprobe'd and cause a problematic reentry into the debug
exception handler.
Signed-off-by: William Cohen <wcohen@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/kprobes.h | 2 +
arch/arm64/kernel/asm-offsets.c | 11 ++++
arch/arm64/kernel/probes/Makefile | 1 +
arch/arm64/kernel/probes/kprobes.c | 5 ++
arch/arm64/kernel/probes/kprobes_trampoline.S | 85 +++++++++++++++++++++++++++
5 files changed, 104 insertions(+)
create mode 100644 arch/arm64/kernel/probes/kprobes_trampoline.S
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 79c9511..61b4915 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -56,5 +56,7 @@ int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index f8e5d47..03dfa27 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -51,6 +51,17 @@ int main(void)
DEFINE(S_X5, offsetof(struct pt_regs, regs[5]));
DEFINE(S_X6, offsetof(struct pt_regs, regs[6]));
DEFINE(S_X7, offsetof(struct pt_regs, regs[7]));
+ DEFINE(S_X8, offsetof(struct pt_regs, regs[8]));
+ DEFINE(S_X10, offsetof(struct pt_regs, regs[10]));
+ DEFINE(S_X12, offsetof(struct pt_regs, regs[12]));
+ DEFINE(S_X14, offsetof(struct pt_regs, regs[14]));
+ DEFINE(S_X16, offsetof(struct pt_regs, regs[16]));
+ DEFINE(S_X18, offsetof(struct pt_regs, regs[18]));
+ DEFINE(S_X20, offsetof(struct pt_regs, regs[20]));
+ DEFINE(S_X22, offsetof(struct pt_regs, regs[22]));
+ DEFINE(S_X24, offsetof(struct pt_regs, regs[24]));
+ DEFINE(S_X26, offsetof(struct pt_regs, regs[26]));
+ DEFINE(S_X28, offsetof(struct pt_regs, regs[28]));
DEFINE(S_LR, offsetof(struct pt_regs, regs[30]));
DEFINE(S_SP, offsetof(struct pt_regs, sp));
#ifdef CONFIG_COMPAT
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
index e184d00..ce06312 100644
--- a/arch/arm64/kernel/probes/Makefile
+++ b/arch/arm64/kernel/probes/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
+ kprobes_trampoline.o \
simulate-insn.o
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 63eb0a1..be1f074 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -576,6 +576,11 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
return false;
}
+void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
+{
+ return NULL;
+}
+
int __init arch_init_kprobes(void)
{
return 0;
diff --git a/arch/arm64/kernel/probes/kprobes_trampoline.S b/arch/arm64/kernel/probes/kprobes_trampoline.S
new file mode 100644
index 0000000..ba37d85
--- /dev/null
+++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
@@ -0,0 +1,85 @@
+/*
+ * trampoline entry and return code for kretprobes.
+ */
+
+#include <linux/linkage.h>
+#include <asm/asm-offsets.h>
+#include <asm/assembler.h>
+
+ .text
+
+.macro save_all_base_regs
+ stp x0, x1, [sp, #S_X0]
+ stp x2, x3, [sp, #S_X2]
+ stp x4, x5, [sp, #S_X4]
+ stp x6, x7, [sp, #S_X6]
+ stp x8, x9, [sp, #S_X8]
+ stp x10, x11, [sp, #S_X10]
+ stp x12, x13, [sp, #S_X12]
+ stp x14, x15, [sp, #S_X14]
+ stp x16, x17, [sp, #S_X16]
+ stp x18, x19, [sp, #S_X18]
+ stp x20, x21, [sp, #S_X20]
+ stp x22, x23, [sp, #S_X22]
+ stp x24, x25, [sp, #S_X24]
+ stp x26, x27, [sp, #S_X26]
+ stp x28, x29, [sp, #S_X28]
+ add x0, sp, #S_FRAME_SIZE
+ stp lr, x0, [sp, #S_LR]
+/*
+ * Construct a useful saved PSTATE
+ */
+ mrs x0, nzcv
+ and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
+ mrs x1, daif
+ and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
+ orr x0, x0, x1
+ mrs x1, CurrentEL
+ and x1, x1, #(3 << 2)
+ orr x0, x1, x0
+ mrs x1, SPSel
+ and x1, x1, #1
+ orr x0, x1, x0
+ str x0, [sp, #S_PSTATE]
+.endm
+
+.macro restore_all_base_regs
+ ldr x0, [sp, #S_PSTATE]
+ and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
+ msr nzcv, x0
+ ldp x0, x1, [sp, #S_X0]
+ ldp x2, x3, [sp, #S_X2]
+ ldp x4, x5, [sp, #S_X4]
+ ldp x6, x7, [sp, #S_X6]
+ ldp x8, x9, [sp, #S_X8]
+ ldp x10, x11, [sp, #S_X10]
+ ldp x12, x13, [sp, #S_X12]
+ ldp x14, x15, [sp, #S_X14]
+ ldp x16, x17, [sp, #S_X16]
+ ldp x18, x19, [sp, #S_X18]
+ ldp x20, x21, [sp, #S_X20]
+ ldp x22, x23, [sp, #S_X22]
+ ldp x24, x25, [sp, #S_X24]
+ ldp x26, x27, [sp, #S_X26]
+ ldp x28, x29, [sp, #S_X28]
+.endm
+
+ENTRY(kretprobe_trampoline)
+
+ sub sp, sp, #S_FRAME_SIZE
+
+ save_all_base_regs
+
+ mov x0, sp
+ bl trampoline_probe_handler
+ /* Replace trampoline address in lr with actual
+ orig_ret_addr return address. */
+ mov lr, x0
+
+ restore_all_base_regs
+
+ add sp, sp, #S_FRAME_SIZE
+
+ ret
+
+ENDPROC(kretprobe_trampoline)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: William Cohen <wcohen@redhat.com>
The trampoline code is used by kretprobes to capture a return from a probed
function. This is done by saving the registers, calling the handler, and
restoring the registers. The code then returns to the original saved caller
return address. It is necessary to do this directly instead of using a
software breakpoint because the code used in processing that breakpoint
could itself be kprobe'd and cause a problematic reentry into the debug
exception handler.
Signed-off-by: William Cohen <wcohen@redhat.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/include/asm/kprobes.h | 2 +
arch/arm64/kernel/asm-offsets.c | 11 ++++
arch/arm64/kernel/probes/Makefile | 1 +
arch/arm64/kernel/probes/kprobes.c | 5 ++
arch/arm64/kernel/probes/kprobes_trampoline.S | 85 +++++++++++++++++++++++++++
5 files changed, 104 insertions(+)
create mode 100644 arch/arm64/kernel/probes/kprobes_trampoline.S
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 79c9511..61b4915 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -56,5 +56,7 @@ int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index f8e5d47..03dfa27 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -51,6 +51,17 @@ int main(void)
DEFINE(S_X5, offsetof(struct pt_regs, regs[5]));
DEFINE(S_X6, offsetof(struct pt_regs, regs[6]));
DEFINE(S_X7, offsetof(struct pt_regs, regs[7]));
+ DEFINE(S_X8, offsetof(struct pt_regs, regs[8]));
+ DEFINE(S_X10, offsetof(struct pt_regs, regs[10]));
+ DEFINE(S_X12, offsetof(struct pt_regs, regs[12]));
+ DEFINE(S_X14, offsetof(struct pt_regs, regs[14]));
+ DEFINE(S_X16, offsetof(struct pt_regs, regs[16]));
+ DEFINE(S_X18, offsetof(struct pt_regs, regs[18]));
+ DEFINE(S_X20, offsetof(struct pt_regs, regs[20]));
+ DEFINE(S_X22, offsetof(struct pt_regs, regs[22]));
+ DEFINE(S_X24, offsetof(struct pt_regs, regs[24]));
+ DEFINE(S_X26, offsetof(struct pt_regs, regs[26]));
+ DEFINE(S_X28, offsetof(struct pt_regs, regs[28]));
DEFINE(S_LR, offsetof(struct pt_regs, regs[30]));
DEFINE(S_SP, offsetof(struct pt_regs, sp));
#ifdef CONFIG_COMPAT
diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
index e184d00..ce06312 100644
--- a/arch/arm64/kernel/probes/Makefile
+++ b/arch/arm64/kernel/probes/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
+ kprobes_trampoline.o \
simulate-insn.o
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 63eb0a1..be1f074 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -576,6 +576,11 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
return false;
}
+void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
+{
+ return NULL;
+}
+
int __init arch_init_kprobes(void)
{
return 0;
diff --git a/arch/arm64/kernel/probes/kprobes_trampoline.S b/arch/arm64/kernel/probes/kprobes_trampoline.S
new file mode 100644
index 0000000..ba37d85
--- /dev/null
+++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
@@ -0,0 +1,85 @@
+/*
+ * trampoline entry and return code for kretprobes.
+ */
+
+#include <linux/linkage.h>
+#include <asm/asm-offsets.h>
+#include <asm/assembler.h>
+
+ .text
+
+.macro save_all_base_regs
+ stp x0, x1, [sp, #S_X0]
+ stp x2, x3, [sp, #S_X2]
+ stp x4, x5, [sp, #S_X4]
+ stp x6, x7, [sp, #S_X6]
+ stp x8, x9, [sp, #S_X8]
+ stp x10, x11, [sp, #S_X10]
+ stp x12, x13, [sp, #S_X12]
+ stp x14, x15, [sp, #S_X14]
+ stp x16, x17, [sp, #S_X16]
+ stp x18, x19, [sp, #S_X18]
+ stp x20, x21, [sp, #S_X20]
+ stp x22, x23, [sp, #S_X22]
+ stp x24, x25, [sp, #S_X24]
+ stp x26, x27, [sp, #S_X26]
+ stp x28, x29, [sp, #S_X28]
+ add x0, sp, #S_FRAME_SIZE
+ stp lr, x0, [sp, #S_LR]
+/*
+ * Construct a useful saved PSTATE
+ */
+ mrs x0, nzcv
+ and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
+ mrs x1, daif
+ and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
+ orr x0, x0, x1
+ mrs x1, CurrentEL
+ and x1, x1, #(3 << 2)
+ orr x0, x1, x0
+ mrs x1, SPSel
+ and x1, x1, #1
+ orr x0, x1, x0
+ str x0, [sp, #S_PSTATE]
+.endm
+
+.macro restore_all_base_regs
+ ldr x0, [sp, #S_PSTATE]
+ and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
+ msr nzcv, x0
+ ldp x0, x1, [sp, #S_X0]
+ ldp x2, x3, [sp, #S_X2]
+ ldp x4, x5, [sp, #S_X4]
+ ldp x6, x7, [sp, #S_X6]
+ ldp x8, x9, [sp, #S_X8]
+ ldp x10, x11, [sp, #S_X10]
+ ldp x12, x13, [sp, #S_X12]
+ ldp x14, x15, [sp, #S_X14]
+ ldp x16, x17, [sp, #S_X16]
+ ldp x18, x19, [sp, #S_X18]
+ ldp x20, x21, [sp, #S_X20]
+ ldp x22, x23, [sp, #S_X22]
+ ldp x24, x25, [sp, #S_X24]
+ ldp x26, x27, [sp, #S_X26]
+ ldp x28, x29, [sp, #S_X28]
+.endm
+
+ENTRY(kretprobe_trampoline)
+
+ sub sp, sp, #S_FRAME_SIZE
+
+ save_all_base_regs
+
+ mov x0, sp
+ bl trampoline_probe_handler
+ /* Replace trampoline address in lr with actual
+ orig_ret_addr return address. */
+ mov lr, x0
+
+ restore_all_base_regs
+
+ add sp, sp, #S_FRAME_SIZE
+
+ ret
+
+ENDPROC(kretprobe_trampoline)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 09/10] arm64: Add kernel return probes support (kretprobes)
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/probes/kprobes.c | 90 +++++++++++++++++++++++++++++++++++++-
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f7d644..6af0e2e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -89,6 +89,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+ select HAVE_KRETPROBES if HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index be1f074..9c70e88 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -578,7 +578,95 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
{
- return NULL;
+ struct kretprobe_instance *ri = NULL;
+ struct hlist_head *head, empty_rp;
+ struct hlist_node *tmp;
+ unsigned long flags, orig_ret_address = 0;
+ unsigned long trampoline_address =
+ (unsigned long)&kretprobe_trampoline;
+ kprobe_opcode_t *correct_ret_addr = NULL;
+
+ INIT_HLIST_HEAD(&empty_rp);
+ kretprobe_hash_lock(current, &head, &flags);
+
+ /*
+ * It is possible to have multiple instances associated with a given
+ * task either because multiple functions in the call path have
+ * return probes installed on them, and/or more than one
+ * return probe was registered for a target function.
+ *
+ * We can handle this because:
+ * - instances are always pushed into the head of the list
+ * - when multiple return probes are registered for the same
+ * function, the (chronologically) first instance's ret_addr
+ * will be the real return address, and all the rest will
+ * point to kretprobe_trampoline.
+ */
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+
+ if (orig_ret_address != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_assert(ri, orig_ret_address, trampoline_address);
+
+ correct_ret_addr = ri->ret_addr;
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+ if (ri->rp && ri->rp->handler) {
+ __this_cpu_write(current_kprobe, &ri->rp->kp);
+ get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+ ri->ret_addr = correct_ret_addr;
+ ri->rp->handler(ri, regs);
+ __this_cpu_write(current_kprobe, NULL);
+ }
+
+ recycle_rp_inst(ri, &empty_rp);
+
+ if (orig_ret_address != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_hash_unlock(current, &flags);
+
+ hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
+ hlist_del(&ri->hlist);
+ kfree(ri);
+ }
+ return (void *)orig_ret_address;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+ struct pt_regs *regs)
+{
+ ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
+
+ /* replace return addr (x30) with trampoline */
+ regs->regs[30] = (long)&kretprobe_trampoline;
+}
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+ return 0;
}
int __init arch_init_kprobes(void)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 09/10] arm64: Add kernel return probes support (kretprobes)
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/probes/kprobes.c | 90 +++++++++++++++++++++++++++++++++++++-
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f7d644..6af0e2e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -89,6 +89,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+ select HAVE_KRETPROBES if HAVE_KPROBES
select IOMMU_DMA if IOMMU_SUPPORT
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index be1f074..9c70e88 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -578,7 +578,95 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
{
- return NULL;
+ struct kretprobe_instance *ri = NULL;
+ struct hlist_head *head, empty_rp;
+ struct hlist_node *tmp;
+ unsigned long flags, orig_ret_address = 0;
+ unsigned long trampoline_address =
+ (unsigned long)&kretprobe_trampoline;
+ kprobe_opcode_t *correct_ret_addr = NULL;
+
+ INIT_HLIST_HEAD(&empty_rp);
+ kretprobe_hash_lock(current, &head, &flags);
+
+ /*
+ * It is possible to have multiple instances associated with a given
+ * task either because multiple functions in the call path have
+ * return probes installed on them, and/or more than one
+ * return probe was registered for a target function.
+ *
+ * We can handle this because:
+ * - instances are always pushed into the head of the list
+ * - when multiple return probes are registered for the same
+ * function, the (chronologically) first instance's ret_addr
+ * will be the real return address, and all the rest will
+ * point to kretprobe_trampoline.
+ */
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+
+ if (orig_ret_address != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_assert(ri, orig_ret_address, trampoline_address);
+
+ correct_ret_addr = ri->ret_addr;
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ orig_ret_address = (unsigned long)ri->ret_addr;
+ if (ri->rp && ri->rp->handler) {
+ __this_cpu_write(current_kprobe, &ri->rp->kp);
+ get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+ ri->ret_addr = correct_ret_addr;
+ ri->rp->handler(ri, regs);
+ __this_cpu_write(current_kprobe, NULL);
+ }
+
+ recycle_rp_inst(ri, &empty_rp);
+
+ if (orig_ret_address != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_hash_unlock(current, &flags);
+
+ hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
+ hlist_del(&ri->hlist);
+ kfree(ri);
+ }
+ return (void *)orig_ret_address;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+ struct pt_regs *regs)
+{
+ ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
+
+ /* replace return addr (x30) with trampoline */
+ regs->regs[30] = (long)&kretprobe_trampoline;
+}
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+ return 0;
}
int __init arch_init_kprobes(void)
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 10/10] kprobes: Add arm64 case in kprobe example module
2016-07-08 16:35 ` David Long
@ 2016-07-08 16:35 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Add info prints in sample kprobe handlers for ARM64
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
samples/kprobes/kprobe_example.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index ed0ca0c..f3b61b4 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -46,6 +46,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
" ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->pc, regs->ex1);
#endif
+#ifdef CONFIG_ARM64
+ pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
+ " pstate = 0x%lx\n",
+ p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
+#endif
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -71,6 +76,10 @@ static void handler_post(struct kprobe *p, struct pt_regs *regs,
printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->ex1);
#endif
+#ifdef CONFIG_ARM64
+ pr_info("<%s> post_handler: p->addr = 0x%p, pstate = 0x%lx\n",
+ p->symbol_name, p->addr, (long)regs->pstate);
+#endif
}
/*
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 10/10] kprobes: Add arm64 case in kprobe example module
@ 2016-07-08 16:35 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-08 16:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Add info prints in sample kprobe handlers for ARM64
Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
Signed-off-by: David A. Long <dave.long@linaro.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
---
samples/kprobes/kprobe_example.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index ed0ca0c..f3b61b4 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -46,6 +46,11 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
" ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->pc, regs->ex1);
#endif
+#ifdef CONFIG_ARM64
+ pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
+ " pstate = 0x%lx\n",
+ p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
+#endif
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -71,6 +76,10 @@ static void handler_post(struct kprobe *p, struct pt_regs *regs,
printk(KERN_INFO "<%s> post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->symbol_name, p->addr, regs->ex1);
#endif
+#ifdef CONFIG_ARM64
+ pr_info("<%s> post_handler: p->addr = 0x%p, pstate = 0x%lx\n",
+ p->symbol_name, p->addr, (long)regs->pstate);
+#endif
}
/*
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 07/10] arm64: kprobes instruction simulation support
2016-07-08 16:35 ` David Long
@ 2016-07-10 22:51 ` Paul Gortmaker
-1 siblings, 0 replies; 147+ messages in thread
From: Paul Gortmaker @ 2016-07-10 22:51 UTC (permalink / raw)
To: David Long
Cc: Catalin Marinas, Huang Shijie, James Morse, Marc Zyngier,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, LKML, Steve Capper, Masami Hiramatsu, Li Bin,
Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On Fri, Jul 8, 2016 at 12:35 PM, David Long <dave.long@linaro.org> wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Kprobes needs simulation of instructions that cannot be stepped
> from a different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using a copy of pt_regs.
>
> The following instruction categories are simulated:
> - All branching instructions(conditional, register, and immediate)
> - Literal access instructions(load-literal, adr/adrp)
>
> Conditional execution is limited to branching instructions in
> ARM v8. If conditions at PSTATE do not match the condition fields
> of opcode, the instruction is effectively NOP.
>
> Thanks to Will Cohen for assorted suggested changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: William Cohen <wcohen@redhat.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
> arch/arm64/include/asm/probes.h | 5 +-
> arch/arm64/kernel/insn.c | 1 +
> arch/arm64/kernel/probes/Makefile | 3 +-
> arch/arm64/kernel/probes/decode-insn.c | 33 ++++-
> arch/arm64/kernel/probes/decode-insn.h | 1 +
> arch/arm64/kernel/probes/kprobes.c | 53 ++++++--
> arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/probes/simulate-insn.h | 28 ++++
> 8 files changed, 327 insertions(+), 15 deletions(-)
> create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
> create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
>
>
[...]
> diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/probes/simulate-insn.c
> new file mode 100644
> index 0000000..429c333
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/simulate-insn.c
> @@ -0,0 +1,218 @@
> +/*
> + * arch/arm64/kernel/probes/simulate-insn.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
Maybe I missed something, but I don't see anything modular about this
code, so why include this?
Paul.
--
> +
> +#include "simulate-insn.h"
> +
> +#define sign_extend(x, signbit) \
> + ((x) | (0 - ((x) & (1 << (signbit)))))
> +
> +#define bbl_displacement(insn) \
> + sign_extend(((insn) & 0x3ffffff) << 2, 27)
> +
> +#define bcond_displacement(insn) \
> + sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
> + disp = ldr_displacement(opcode);
> + load_addr = (s32 *) (addr + disp);
> +
> + set_x_reg(regs, xn, *load_addr);
> +
> + instruction_pointer_set(regs, instruction_pointer(regs) + 4);
> +}
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 07/10] arm64: kprobes instruction simulation support
@ 2016-07-10 22:51 ` Paul Gortmaker
0 siblings, 0 replies; 147+ messages in thread
From: Paul Gortmaker @ 2016-07-10 22:51 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 8, 2016 at 12:35 PM, David Long <dave.long@linaro.org> wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Kprobes needs simulation of instructions that cannot be stepped
> from a different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using a copy of pt_regs.
>
> The following instruction categories are simulated:
> - All branching instructions(conditional, register, and immediate)
> - Literal access instructions(load-literal, adr/adrp)
>
> Conditional execution is limited to branching instructions in
> ARM v8. If conditions at PSTATE do not match the condition fields
> of opcode, the instruction is effectively NOP.
>
> Thanks to Will Cohen for assorted suggested changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: William Cohen <wcohen@redhat.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
> arch/arm64/include/asm/probes.h | 5 +-
> arch/arm64/kernel/insn.c | 1 +
> arch/arm64/kernel/probes/Makefile | 3 +-
> arch/arm64/kernel/probes/decode-insn.c | 33 ++++-
> arch/arm64/kernel/probes/decode-insn.h | 1 +
> arch/arm64/kernel/probes/kprobes.c | 53 ++++++--
> arch/arm64/kernel/probes/simulate-insn.c | 218 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/probes/simulate-insn.h | 28 ++++
> 8 files changed, 327 insertions(+), 15 deletions(-)
> create mode 100644 arch/arm64/kernel/probes/simulate-insn.c
> create mode 100644 arch/arm64/kernel/probes/simulate-insn.h
>
>
[...]
> diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/probes/simulate-insn.c
> new file mode 100644
> index 0000000..429c333
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/simulate-insn.c
> @@ -0,0 +1,218 @@
> +/*
> + * arch/arm64/kernel/probes/simulate-insn.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
Maybe I missed something, but I don't see anything modular about this
code, so why include this?
Paul.
--
> +
> +#include "simulate-insn.h"
> +
> +#define sign_extend(x, signbit) \
> + ((x) | (0 - ((x) & (1 << (signbit)))))
> +
> +#define bbl_displacement(insn) \
> + sign_extend(((insn) & 0x3ffffff) << 2, 27)
> +
> +#define bcond_displacement(insn) \
> + sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
> + disp = ldr_displacement(opcode);
> + load_addr = (s32 *) (addr + disp);
> +
> + set_x_reg(regs, xn, *load_addr);
> +
> + instruction_pointer_set(regs, instruction_pointer(regs) + 4);
> +}
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-08 16:35 ` David Long
@ 2016-07-14 16:22 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-14 16:22 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> David A. Long (3):
> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> arm64: Add more test functions to insn.c
> arm64: add conditional instruction simulation support
>
> Pratyush Anand (2):
> arm64: Blacklist non-kprobe-able symbol
> arm64: Treat all entry code as non-kprobe-able
>
> Sandeepa Prabhu (4):
> arm64: Kprobes with single stepping support
> arm64: kprobes instruction simulation support
> arm64: Add kernel return probes support (kretprobes)
> kprobes: Add arm64 case in kprobe example module
>
> William Cohen (1):
> arm64: Add trampoline code for kretprobes
I applied these patches on top of the arm64 for-next/core branch an
tried to run the resulting kernel in a guest (on a Juno platform using
both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
the kernel fails to boot with lots of "Unexpected kernel single-step
exception at EL1".
Did you manage to run Kprobes in a guest before?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-14 16:22 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-14 16:22 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> David A. Long (3):
> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> arm64: Add more test functions to insn.c
> arm64: add conditional instruction simulation support
>
> Pratyush Anand (2):
> arm64: Blacklist non-kprobe-able symbol
> arm64: Treat all entry code as non-kprobe-able
>
> Sandeepa Prabhu (4):
> arm64: Kprobes with single stepping support
> arm64: kprobes instruction simulation support
> arm64: Add kernel return probes support (kretprobes)
> kprobes: Add arm64 case in kprobe example module
>
> William Cohen (1):
> arm64: Add trampoline code for kretprobes
I applied these patches on top of the arm64 for-next/core branch an
tried to run the resulting kernel in a guest (on a Juno platform using
both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
the kernel fails to boot with lots of "Unexpected kernel single-step
exception at EL1".
Did you manage to run Kprobes in a guest before?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-14 16:22 ` Catalin Marinas
@ 2016-07-14 17:09 ` William Cohen
-1 siblings, 0 replies; 147+ messages in thread
From: William Cohen @ 2016-07-14 17:09 UTC (permalink / raw)
To: Catalin Marinas, David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, linux-arm-kernel, linux-kernel,
Steve Capper, Masami Hiramatsu, Li Bin, Jisheng Zhang,
Mark Rutland, Daniel Thompson, Vladimir Murzin, Petr Mladek,
Ard Biesheuvel, Jens Wiklander, Robin Murphy, Mark Brown,
Suzuki K Poulose, Dave P Martin, Andrey Ryabinin, yalin wang,
Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> David A. Long (3):
>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>> arm64: Add more test functions to insn.c
>> arm64: add conditional instruction simulation support
>>
>> Pratyush Anand (2):
>> arm64: Blacklist non-kprobe-able symbol
>> arm64: Treat all entry code as non-kprobe-able
>>
>> Sandeepa Prabhu (4):
>> arm64: Kprobes with single stepping support
>> arm64: kprobes instruction simulation support
>> arm64: Add kernel return probes support (kretprobes)
>> kprobes: Add arm64 case in kprobe example module
>>
>> William Cohen (1):
>> arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
>
> Did you manage to run Kprobes in a guest before?
>
Hi,
I ran the systemtap testsuite several times on a physical machine running a kernel with the kprobe v15 patches without problem. Shouldn't the guest machine behave in the same manner as a host machine for single stepping and exception handling? If the guest machine is failing, wouldn't that suggest there is a problem with the KVM handling of single stepping for guests?
-Will Cohen
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-14 17:09 ` William Cohen
0 siblings, 0 replies; 147+ messages in thread
From: William Cohen @ 2016-07-14 17:09 UTC (permalink / raw)
To: linux-arm-kernel
On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> David A. Long (3):
>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>> arm64: Add more test functions to insn.c
>> arm64: add conditional instruction simulation support
>>
>> Pratyush Anand (2):
>> arm64: Blacklist non-kprobe-able symbol
>> arm64: Treat all entry code as non-kprobe-able
>>
>> Sandeepa Prabhu (4):
>> arm64: Kprobes with single stepping support
>> arm64: kprobes instruction simulation support
>> arm64: Add kernel return probes support (kretprobes)
>> kprobes: Add arm64 case in kprobe example module
>>
>> William Cohen (1):
>> arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
>
> Did you manage to run Kprobes in a guest before?
>
Hi,
I ran the systemtap testsuite several times on a physical machine running a kernel with the kprobe v15 patches without problem. Shouldn't the guest machine behave in the same manner as a host machine for single stepping and exception handling? If the guest machine is failing, wouldn't that suggest there is a problem with the KVM handling of single stepping for guests?
-Will Cohen
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-14 16:22 ` Catalin Marinas
@ 2016-07-14 17:56 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-14 17:56 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> David A. Long (3):
>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>> arm64: Add more test functions to insn.c
>> arm64: add conditional instruction simulation support
>>
>> Pratyush Anand (2):
>> arm64: Blacklist non-kprobe-able symbol
>> arm64: Treat all entry code as non-kprobe-able
>>
>> Sandeepa Prabhu (4):
>> arm64: Kprobes with single stepping support
>> arm64: kprobes instruction simulation support
>> arm64: Add kernel return probes support (kretprobes)
>> kprobes: Add arm64 case in kprobe example module
>>
>> William Cohen (1):
>> arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
>
> Did you manage to run Kprobes in a guest before?
>
I have not run this code as a guest, I have only tested it natively.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-14 17:56 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-14 17:56 UTC (permalink / raw)
To: linux-arm-kernel
On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> David A. Long (3):
>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>> arm64: Add more test functions to insn.c
>> arm64: add conditional instruction simulation support
>>
>> Pratyush Anand (2):
>> arm64: Blacklist non-kprobe-able symbol
>> arm64: Treat all entry code as non-kprobe-able
>>
>> Sandeepa Prabhu (4):
>> arm64: Kprobes with single stepping support
>> arm64: kprobes instruction simulation support
>> arm64: Add kernel return probes support (kretprobes)
>> kprobes: Add arm64 case in kprobe example module
>>
>> William Cohen (1):
>> arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
>
> Did you manage to run Kprobes in a guest before?
>
I have not run this code as a guest, I have only tested it natively.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-14 17:09 ` William Cohen
@ 2016-07-15 7:50 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 7:50 UTC (permalink / raw)
To: William Cohen
Cc: David Long, Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> > On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> >> David A. Long (3):
> >> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> >> arm64: Add more test functions to insn.c
> >> arm64: add conditional instruction simulation support
> >>
> >> Pratyush Anand (2):
> >> arm64: Blacklist non-kprobe-able symbol
> >> arm64: Treat all entry code as non-kprobe-able
> >>
> >> Sandeepa Prabhu (4):
> >> arm64: Kprobes with single stepping support
> >> arm64: kprobes instruction simulation support
> >> arm64: Add kernel return probes support (kretprobes)
> >> kprobes: Add arm64 case in kprobe example module
> >>
> >> William Cohen (1):
> >> arm64: Add trampoline code for kretprobes
> >
> > I applied these patches on top of the arm64 for-next/core branch an
> > tried to run the resulting kernel in a guest (on a Juno platform using
> > both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> > the kernel fails to boot with lots of "Unexpected kernel single-step
> > exception at EL1".
> >
> > Did you manage to run Kprobes in a guest before?
>
> I ran the systemtap testsuite several times on a physical machine
> running a kernel with the kprobe v15 patches without problem.
> Shouldn't the guest machine behave in the same manner as a host
> machine for single stepping and exception handling? If the guest
> machine is failing, wouldn't that suggest there is a problem with the
> KVM handling of single stepping for guests?
It didn't fail for me on the host either. What's strange is that on some
occasions even the guest managed to get to a prompt. I'll do more tests
today on different CPU configurations, just to rule out potential
hardware issues. If not hardware related, it's possible that the
interaction with KVM doesn't work as expected, maybe the
saving/restoring of the guest debug state loses information.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-15 7:50 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 7:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
> > On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> >> David A. Long (3):
> >> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> >> arm64: Add more test functions to insn.c
> >> arm64: add conditional instruction simulation support
> >>
> >> Pratyush Anand (2):
> >> arm64: Blacklist non-kprobe-able symbol
> >> arm64: Treat all entry code as non-kprobe-able
> >>
> >> Sandeepa Prabhu (4):
> >> arm64: Kprobes with single stepping support
> >> arm64: kprobes instruction simulation support
> >> arm64: Add kernel return probes support (kretprobes)
> >> kprobes: Add arm64 case in kprobe example module
> >>
> >> William Cohen (1):
> >> arm64: Add trampoline code for kretprobes
> >
> > I applied these patches on top of the arm64 for-next/core branch an
> > tried to run the resulting kernel in a guest (on a Juno platform using
> > both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> > the kernel fails to boot with lots of "Unexpected kernel single-step
> > exception at EL1".
> >
> > Did you manage to run Kprobes in a guest before?
>
> I ran the systemtap testsuite several times on a physical machine
> running a kernel with the kprobe v15 patches without problem.
> Shouldn't the guest machine behave in the same manner as a host
> machine for single stepping and exception handling? If the guest
> machine is failing, wouldn't that suggest there is a problem with the
> KVM handling of single stepping for guests?
It didn't fail for me on the host either. What's strange is that on some
occasions even the guest managed to get to a prompt. I'll do more tests
today on different CPU configurations, just to rule out potential
hardware issues. If not hardware related, it's possible that the
interaction with KVM doesn't work as expected, maybe the
saving/restoring of the guest debug state loses information.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-15 7:50 ` Catalin Marinas
@ 2016-07-15 8:01 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 8:01 UTC (permalink / raw)
To: Catalin Marinas, William Cohen
Cc: David Long, Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Yang Shi, Mark Brown, Sandeepa Prabhu, Alex Bennée,
Adam Buchbinder, linux-arm-kernel, Ard Biesheuvel, linux-kernel,
James Morse, Masami Hiramatsu, Andrew Morton, Robin Murphy,
Jens Wiklander, Christoffer Dall
On 15/07/16 08:50, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>> David A. Long (3):
>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>> arm64: Add more test functions to insn.c
>>>> arm64: add conditional instruction simulation support
>>>>
>>>> Pratyush Anand (2):
>>>> arm64: Blacklist non-kprobe-able symbol
>>>> arm64: Treat all entry code as non-kprobe-able
>>>>
>>>> Sandeepa Prabhu (4):
>>>> arm64: Kprobes with single stepping support
>>>> arm64: kprobes instruction simulation support
>>>> arm64: Add kernel return probes support (kretprobes)
>>>> kprobes: Add arm64 case in kprobe example module
>>>>
>>>> William Cohen (1):
>>>> arm64: Add trampoline code for kretprobes
>>>
>>> I applied these patches on top of the arm64 for-next/core branch an
>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>> exception at EL1".
>>>
>>> Did you manage to run Kprobes in a guest before?
>>
>> I ran the systemtap testsuite several times on a physical machine
>> running a kernel with the kprobe v15 patches without problem.
>> Shouldn't the guest machine behave in the same manner as a host
>> machine for single stepping and exception handling? If the guest
>> machine is failing, wouldn't that suggest there is a problem with the
>> KVM handling of single stepping for guests?
>
> It didn't fail for me on the host either. What's strange is that on some
> occasions even the guest managed to get to a prompt. I'll do more tests
> today on different CPU configurations, just to rule out potential
> hardware issues. If not hardware related, it's possible that the
> interaction with KVM doesn't work as expected, maybe the
> saving/restoring of the guest debug state loses information.
Could well be the latter. I'll try to have a look, but Alex Bennée (on
cc) is our man when it comes to the KVM debug infrastructure.
Alex, any chance you could try this and shed some light on it?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-15 8:01 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 8:01 UTC (permalink / raw)
To: linux-arm-kernel
On 15/07/16 08:50, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>> David A. Long (3):
>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>> arm64: Add more test functions to insn.c
>>>> arm64: add conditional instruction simulation support
>>>>
>>>> Pratyush Anand (2):
>>>> arm64: Blacklist non-kprobe-able symbol
>>>> arm64: Treat all entry code as non-kprobe-able
>>>>
>>>> Sandeepa Prabhu (4):
>>>> arm64: Kprobes with single stepping support
>>>> arm64: kprobes instruction simulation support
>>>> arm64: Add kernel return probes support (kretprobes)
>>>> kprobes: Add arm64 case in kprobe example module
>>>>
>>>> William Cohen (1):
>>>> arm64: Add trampoline code for kretprobes
>>>
>>> I applied these patches on top of the arm64 for-next/core branch an
>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>> exception at EL1".
>>>
>>> Did you manage to run Kprobes in a guest before?
>>
>> I ran the systemtap testsuite several times on a physical machine
>> running a kernel with the kprobe v15 patches without problem.
>> Shouldn't the guest machine behave in the same manner as a host
>> machine for single stepping and exception handling? If the guest
>> machine is failing, wouldn't that suggest there is a problem with the
>> KVM handling of single stepping for guests?
>
> It didn't fail for me on the host either. What's strange is that on some
> occasions even the guest managed to get to a prompt. I'll do more tests
> today on different CPU configurations, just to rule out potential
> hardware issues. If not hardware related, it's possible that the
> interaction with KVM doesn't work as expected, maybe the
> saving/restoring of the guest debug state loses information.
Could well be the latter. I'll try to have a look, but Alex Benn?e (on
cc) is our man when it comes to the KVM debug infrastructure.
Alex, any chance you could try this and shed some light on it?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-15 8:01 ` Marc Zyngier
@ 2016-07-15 8:59 ` Alex Bennée
-1 siblings, 0 replies; 147+ messages in thread
From: Alex Bennée @ 2016-07-15 8:59 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, William Cohen, David Long, Mark Rutland,
Petr Mladek, Zi Shen Lim, Will Deacon, Andrey Ryabinin,
yalin wang, Li Bin, John Blackwood, Pratyush Anand,
Daniel Thompson, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Yang Shi,
Mark Brown, Sandeepa Prabhu, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
Marc Zyngier <marc.zyngier@arm.com> writes:
> On 15/07/16 08:50, Catalin Marinas wrote:
>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>> David A. Long (3):
>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>> arm64: Add more test functions to insn.c
>>>>> arm64: add conditional instruction simulation support
>>>>>
>>>>> Pratyush Anand (2):
>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>
>>>>> Sandeepa Prabhu (4):
>>>>> arm64: Kprobes with single stepping support
>>>>> arm64: kprobes instruction simulation support
>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>
>>>>> William Cohen (1):
>>>>> arm64: Add trampoline code for kretprobes
>>>>
>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>> exception at EL1".
>>>>
>>>> Did you manage to run Kprobes in a guest before?
>>>
>>> I ran the systemtap testsuite several times on a physical machine
>>> running a kernel with the kprobe v15 patches without problem.
>>> Shouldn't the guest machine behave in the same manner as a host
>>> machine for single stepping and exception handling? If the guest
>>> machine is failing, wouldn't that suggest there is a problem with the
>>> KVM handling of single stepping for guests?
>>
>> It didn't fail for me on the host either. What's strange is that on some
>> occasions even the guest managed to get to a prompt. I'll do more tests
>> today on different CPU configurations, just to rule out potential
>> hardware issues. If not hardware related, it's possible that the
>> interaction with KVM doesn't work as expected, maybe the
>> saving/restoring of the guest debug state loses information.
>
> Could well be the latter. I'll try to have a look, but Alex Bennée (on
> cc) is our man when it comes to the KVM debug infrastructure.
>
> Alex, any chance you could try this and shed some light on it?
Sure I'll have a look. There are problems with running gdb inside a
guest while trying to debug from outside associated with single-stepping
but none of this should get in the way if your not debugging the guest.
Let me get my system spun up and see if I can reproduce.
Shall I just apply this series on top of the current master?
--
Alex Bennée
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-15 8:59 ` Alex Bennée
0 siblings, 0 replies; 147+ messages in thread
From: Alex Bennée @ 2016-07-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Marc Zyngier <marc.zyngier@arm.com> writes:
> On 15/07/16 08:50, Catalin Marinas wrote:
>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>> David A. Long (3):
>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>> arm64: Add more test functions to insn.c
>>>>> arm64: add conditional instruction simulation support
>>>>>
>>>>> Pratyush Anand (2):
>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>
>>>>> Sandeepa Prabhu (4):
>>>>> arm64: Kprobes with single stepping support
>>>>> arm64: kprobes instruction simulation support
>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>
>>>>> William Cohen (1):
>>>>> arm64: Add trampoline code for kretprobes
>>>>
>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>> exception at EL1".
>>>>
>>>> Did you manage to run Kprobes in a guest before?
>>>
>>> I ran the systemtap testsuite several times on a physical machine
>>> running a kernel with the kprobe v15 patches without problem.
>>> Shouldn't the guest machine behave in the same manner as a host
>>> machine for single stepping and exception handling? If the guest
>>> machine is failing, wouldn't that suggest there is a problem with the
>>> KVM handling of single stepping for guests?
>>
>> It didn't fail for me on the host either. What's strange is that on some
>> occasions even the guest managed to get to a prompt. I'll do more tests
>> today on different CPU configurations, just to rule out potential
>> hardware issues. If not hardware related, it's possible that the
>> interaction with KVM doesn't work as expected, maybe the
>> saving/restoring of the guest debug state loses information.
>
> Could well be the latter. I'll try to have a look, but Alex Benn?e (on
> cc) is our man when it comes to the KVM debug infrastructure.
>
> Alex, any chance you could try this and shed some light on it?
Sure I'll have a look. There are problems with running gdb inside a
guest while trying to debug from outside associated with single-stepping
but none of this should get in the way if your not debugging the guest.
Let me get my system spun up and see if I can reproduce.
Shall I just apply this series on top of the current master?
--
Alex Benn?e
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-15 8:59 ` Alex Bennée
@ 2016-07-15 9:04 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 9:04 UTC (permalink / raw)
To: Alex Bennée
Cc: Catalin Marinas, William Cohen, David Long, Mark Rutland,
Petr Mladek, Zi Shen Lim, Will Deacon, Andrey Ryabinin,
yalin wang, Li Bin, John Blackwood, Pratyush Anand,
Daniel Thompson, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Yang Shi,
Mark Brown, Sandeepa Prabhu, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 15/07/16 09:59, Alex Bennée wrote:
>
> Marc Zyngier <marc.zyngier@arm.com> writes:
>
>> On 15/07/16 08:50, Catalin Marinas wrote:
>>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>>> David A. Long (3):
>>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>>> arm64: Add more test functions to insn.c
>>>>>> arm64: add conditional instruction simulation support
>>>>>>
>>>>>> Pratyush Anand (2):
>>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>>
>>>>>> Sandeepa Prabhu (4):
>>>>>> arm64: Kprobes with single stepping support
>>>>>> arm64: kprobes instruction simulation support
>>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>>
>>>>>> William Cohen (1):
>>>>>> arm64: Add trampoline code for kretprobes
>>>>>
>>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>>> exception at EL1".
>>>>>
>>>>> Did you manage to run Kprobes in a guest before?
>>>>
>>>> I ran the systemtap testsuite several times on a physical machine
>>>> running a kernel with the kprobe v15 patches without problem.
>>>> Shouldn't the guest machine behave in the same manner as a host
>>>> machine for single stepping and exception handling? If the guest
>>>> machine is failing, wouldn't that suggest there is a problem with the
>>>> KVM handling of single stepping for guests?
>>>
>>> It didn't fail for me on the host either. What's strange is that on some
>>> occasions even the guest managed to get to a prompt. I'll do more tests
>>> today on different CPU configurations, just to rule out potential
>>> hardware issues. If not hardware related, it's possible that the
>>> interaction with KVM doesn't work as expected, maybe the
>>> saving/restoring of the guest debug state loses information.
>>
>> Could well be the latter. I'll try to have a look, but Alex Bennée (on
>> cc) is our man when it comes to the KVM debug infrastructure.
>>
>> Alex, any chance you could try this and shed some light on it?
>
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
>
> Let me get my system spun up and see if I can reproduce.
>
> Shall I just apply this series on top of the current master?
I'm trying with -rc7 at the moment.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-15 9:04 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 9:04 UTC (permalink / raw)
To: linux-arm-kernel
On 15/07/16 09:59, Alex Benn?e wrote:
>
> Marc Zyngier <marc.zyngier@arm.com> writes:
>
>> On 15/07/16 08:50, Catalin Marinas wrote:
>>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>>> David A. Long (3):
>>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>>> arm64: Add more test functions to insn.c
>>>>>> arm64: add conditional instruction simulation support
>>>>>>
>>>>>> Pratyush Anand (2):
>>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>>
>>>>>> Sandeepa Prabhu (4):
>>>>>> arm64: Kprobes with single stepping support
>>>>>> arm64: kprobes instruction simulation support
>>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>>
>>>>>> William Cohen (1):
>>>>>> arm64: Add trampoline code for kretprobes
>>>>>
>>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>>> exception at EL1".
>>>>>
>>>>> Did you manage to run Kprobes in a guest before?
>>>>
>>>> I ran the systemtap testsuite several times on a physical machine
>>>> running a kernel with the kprobe v15 patches without problem.
>>>> Shouldn't the guest machine behave in the same manner as a host
>>>> machine for single stepping and exception handling? If the guest
>>>> machine is failing, wouldn't that suggest there is a problem with the
>>>> KVM handling of single stepping for guests?
>>>
>>> It didn't fail for me on the host either. What's strange is that on some
>>> occasions even the guest managed to get to a prompt. I'll do more tests
>>> today on different CPU configurations, just to rule out potential
>>> hardware issues. If not hardware related, it's possible that the
>>> interaction with KVM doesn't work as expected, maybe the
>>> saving/restoring of the guest debug state loses information.
>>
>> Could well be the latter. I'll try to have a look, but Alex Benn?e (on
>> cc) is our man when it comes to the KVM debug infrastructure.
>>
>> Alex, any chance you could try this and shed some light on it?
>
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
>
> Let me get my system spun up and see if I can reproduce.
>
> Shall I just apply this series on top of the current master?
I'm trying with -rc7 at the moment.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-15 8:59 ` Alex Bennée
@ 2016-07-15 9:53 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 9:53 UTC (permalink / raw)
To: Alex Bennée
Cc: Catalin Marinas, William Cohen, David Long, Mark Rutland,
Petr Mladek, Zi Shen Lim, Will Deacon, Andrey Ryabinin,
yalin wang, Li Bin, John Blackwood, Pratyush Anand,
Daniel Thompson, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Yang Shi,
Mark Brown, Sandeepa Prabhu, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 15/07/16 09:59, Alex Bennée wrote:
>
> Marc Zyngier <marc.zyngier@arm.com> writes:
>
>> On 15/07/16 08:50, Catalin Marinas wrote:
>>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>>> David A. Long (3):
>>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>>> arm64: Add more test functions to insn.c
>>>>>> arm64: add conditional instruction simulation support
>>>>>>
>>>>>> Pratyush Anand (2):
>>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>>
>>>>>> Sandeepa Prabhu (4):
>>>>>> arm64: Kprobes with single stepping support
>>>>>> arm64: kprobes instruction simulation support
>>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>>
>>>>>> William Cohen (1):
>>>>>> arm64: Add trampoline code for kretprobes
>>>>>
>>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>>> exception at EL1".
>>>>>
>>>>> Did you manage to run Kprobes in a guest before?
>>>>
>>>> I ran the systemtap testsuite several times on a physical machine
>>>> running a kernel with the kprobe v15 patches without problem.
>>>> Shouldn't the guest machine behave in the same manner as a host
>>>> machine for single stepping and exception handling? If the guest
>>>> machine is failing, wouldn't that suggest there is a problem with the
>>>> KVM handling of single stepping for guests?
>>>
>>> It didn't fail for me on the host either. What's strange is that on some
>>> occasions even the guest managed to get to a prompt. I'll do more tests
>>> today on different CPU configurations, just to rule out potential
>>> hardware issues. If not hardware related, it's possible that the
>>> interaction with KVM doesn't work as expected, maybe the
>>> saving/restoring of the guest debug state loses information.
>>
>> Could well be the latter. I'll try to have a look, but Alex Bennée (on
>> cc) is our man when it comes to the KVM debug infrastructure.
>>
>> Alex, any chance you could try this and shed some light on it?
>
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
>
> Let me get my system spun up and see if I can reproduce.
>
> Shall I just apply this series on top of the current master?
I managed to reproduce it by taskset-ing 2 vcpus on the same physical
CPU, and trying a few dozen times on Juno-r1. It is not easy to trigger,
but when it happens it is quite bad.
Warning, pure speculation ahead: I suspect that we preempt a vcpu with
single-step enabled, somehow fail to clear the SS state, schedule
another vcpu that inherits that state and takes this unexpected SS
exception.
/me goes and have a look...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-15 9:53 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-15 9:53 UTC (permalink / raw)
To: linux-arm-kernel
On 15/07/16 09:59, Alex Benn?e wrote:
>
> Marc Zyngier <marc.zyngier@arm.com> writes:
>
>> On 15/07/16 08:50, Catalin Marinas wrote:
>>> On Thu, Jul 14, 2016 at 01:09:08PM -0400, William Cohen wrote:
>>>> On 07/14/2016 12:22 PM, Catalin Marinas wrote:
>>>>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>>>>> David A. Long (3):
>>>>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>>>>> arm64: Add more test functions to insn.c
>>>>>> arm64: add conditional instruction simulation support
>>>>>>
>>>>>> Pratyush Anand (2):
>>>>>> arm64: Blacklist non-kprobe-able symbol
>>>>>> arm64: Treat all entry code as non-kprobe-able
>>>>>>
>>>>>> Sandeepa Prabhu (4):
>>>>>> arm64: Kprobes with single stepping support
>>>>>> arm64: kprobes instruction simulation support
>>>>>> arm64: Add kernel return probes support (kretprobes)
>>>>>> kprobes: Add arm64 case in kprobe example module
>>>>>>
>>>>>> William Cohen (1):
>>>>>> arm64: Add trampoline code for kretprobes
>>>>>
>>>>> I applied these patches on top of the arm64 for-next/core branch an
>>>>> tried to run the resulting kernel in a guest (on a Juno platform using
>>>>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>>>>> the kernel fails to boot with lots of "Unexpected kernel single-step
>>>>> exception at EL1".
>>>>>
>>>>> Did you manage to run Kprobes in a guest before?
>>>>
>>>> I ran the systemtap testsuite several times on a physical machine
>>>> running a kernel with the kprobe v15 patches without problem.
>>>> Shouldn't the guest machine behave in the same manner as a host
>>>> machine for single stepping and exception handling? If the guest
>>>> machine is failing, wouldn't that suggest there is a problem with the
>>>> KVM handling of single stepping for guests?
>>>
>>> It didn't fail for me on the host either. What's strange is that on some
>>> occasions even the guest managed to get to a prompt. I'll do more tests
>>> today on different CPU configurations, just to rule out potential
>>> hardware issues. If not hardware related, it's possible that the
>>> interaction with KVM doesn't work as expected, maybe the
>>> saving/restoring of the guest debug state loses information.
>>
>> Could well be the latter. I'll try to have a look, but Alex Benn?e (on
>> cc) is our man when it comes to the KVM debug infrastructure.
>>
>> Alex, any chance you could try this and shed some light on it?
>
> Sure I'll have a look. There are problems with running gdb inside a
> guest while trying to debug from outside associated with single-stepping
> but none of this should get in the way if your not debugging the guest.
>
> Let me get my system spun up and see if I can reproduce.
>
> Shall I just apply this series on top of the current master?
I managed to reproduce it by taskset-ing 2 vcpus on the same physical
CPU, and trying a few dozen times on Juno-r1. It is not easy to trigger,
but when it happens it is quite bad.
Warning, pure speculation ahead: I suspect that we preempt a vcpu with
single-step enabled, somehow fail to clear the SS state, schedule
another vcpu that inherits that state and takes this unexpected SS
exception.
/me goes and have a look...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-08 16:35 ` David Long
@ 2016-07-15 10:57 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 10:57 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -74,6 +74,7 @@
> #define COMPAT_PT_DATA_ADDR 0x10004
> #define COMPAT_PT_TEXT_END_ADDR 0x10008
> #ifndef __ASSEMBLY__
> +#include <linux/bug.h>
>
> /* sizeof(struct user) for AArch32 */
> #define COMPAT_USER_SZ 296
> @@ -119,6 +120,8 @@ struct pt_regs {
> u64 syscallno;
> };
>
> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
> +
> #define arch_has_single_step() (1)
>
> #ifdef CONFIG_COMPAT
> @@ -147,6 +150,55 @@ struct pt_regs {
> #define user_stack_pointer(regs) \
> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>
> +extern int regs_query_register_offset(const char *name);
> +extern const char *regs_query_register_name(unsigned int offset);
Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
these patches applied but couldn't find any use.
> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
make it static and remove the declaration?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-15 10:57 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 10:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -74,6 +74,7 @@
> #define COMPAT_PT_DATA_ADDR 0x10004
> #define COMPAT_PT_TEXT_END_ADDR 0x10008
> #ifndef __ASSEMBLY__
> +#include <linux/bug.h>
>
> /* sizeof(struct user) for AArch32 */
> #define COMPAT_USER_SZ 296
> @@ -119,6 +120,8 @@ struct pt_regs {
> u64 syscallno;
> };
>
> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
> +
> #define arch_has_single_step() (1)
>
> #ifdef CONFIG_COMPAT
> @@ -147,6 +150,55 @@ struct pt_regs {
> #define user_stack_pointer(regs) \
> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>
> +extern int regs_query_register_offset(const char *name);
> +extern const char *regs_query_register_name(unsigned int offset);
Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
these patches applied but couldn't find any use.
> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
make it static and remove the declaration?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-15 10:57 ` Catalin Marinas
@ 2016-07-15 14:51 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-15 14:51 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -74,6 +74,7 @@
>> #define COMPAT_PT_DATA_ADDR 0x10004
>> #define COMPAT_PT_TEXT_END_ADDR 0x10008
>> #ifndef __ASSEMBLY__
>> +#include <linux/bug.h>
>>
>> /* sizeof(struct user) for AArch32 */
>> #define COMPAT_USER_SZ 296
>> @@ -119,6 +120,8 @@ struct pt_regs {
>> u64 syscallno;
>> };
>>
>> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
>> +
>> #define arch_has_single_step() (1)
>>
>> #ifdef CONFIG_COMPAT
>> @@ -147,6 +150,55 @@ struct pt_regs {
>> #define user_stack_pointer(regs) \
>> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>
>> +extern int regs_query_register_offset(const char *name);
>> +extern const char *regs_query_register_name(unsigned int offset);
>
> Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
> these patches applied but couldn't find any use.
>
It's referenced in kernel/trace/trace_probe.c.
>> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
>
> This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> make it static and remove the declaration?
>
OK.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-15 14:51 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-15 14:51 UTC (permalink / raw)
To: linux-arm-kernel
On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -74,6 +74,7 @@
>> #define COMPAT_PT_DATA_ADDR 0x10004
>> #define COMPAT_PT_TEXT_END_ADDR 0x10008
>> #ifndef __ASSEMBLY__
>> +#include <linux/bug.h>
>>
>> /* sizeof(struct user) for AArch32 */
>> #define COMPAT_USER_SZ 296
>> @@ -119,6 +120,8 @@ struct pt_regs {
>> u64 syscallno;
>> };
>>
>> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
>> +
>> #define arch_has_single_step() (1)
>>
>> #ifdef CONFIG_COMPAT
>> @@ -147,6 +150,55 @@ struct pt_regs {
>> #define user_stack_pointer(regs) \
>> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>
>> +extern int regs_query_register_offset(const char *name);
>> +extern const char *regs_query_register_name(unsigned int offset);
>
> Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
> these patches applied but couldn't find any use.
>
It's referenced in kernel/trace/trace_probe.c.
>> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
>
> This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> make it static and remove the declaration?
>
OK.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-15 14:51 ` David Long
@ 2016-07-15 15:13 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 15:13 UTC (permalink / raw)
To: David Long
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
> On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> > On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> > > --- a/arch/arm64/include/asm/ptrace.h
> > > +++ b/arch/arm64/include/asm/ptrace.h
> > > @@ -74,6 +74,7 @@
> > > #define COMPAT_PT_DATA_ADDR 0x10004
> > > #define COMPAT_PT_TEXT_END_ADDR 0x10008
> > > #ifndef __ASSEMBLY__
> > > +#include <linux/bug.h>
> > >
> > > /* sizeof(struct user) for AArch32 */
> > > #define COMPAT_USER_SZ 296
> > > @@ -119,6 +120,8 @@ struct pt_regs {
> > > u64 syscallno;
> > > };
> > >
> > > +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
> > > +
> > > #define arch_has_single_step() (1)
> > >
> > > #ifdef CONFIG_COMPAT
> > > @@ -147,6 +150,55 @@ struct pt_regs {
> > > #define user_stack_pointer(regs) \
> > > (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
> > >
> > > +extern int regs_query_register_offset(const char *name);
> > > +extern const char *regs_query_register_name(unsigned int offset);
> >
> > Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
> > these patches applied but couldn't find any use.
>
> It's referenced in kernel/trace/trace_probe.c.
I meant regs_query_register_name() (vim completion wrote the first one).
> > > +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
> >
> > This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> > make it static and remove the declaration?
>
> OK.
I can change it locally.
Are these going to be used in the future by uprobes?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-15 15:13 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 15:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
> On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> > On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> > > --- a/arch/arm64/include/asm/ptrace.h
> > > +++ b/arch/arm64/include/asm/ptrace.h
> > > @@ -74,6 +74,7 @@
> > > #define COMPAT_PT_DATA_ADDR 0x10004
> > > #define COMPAT_PT_TEXT_END_ADDR 0x10008
> > > #ifndef __ASSEMBLY__
> > > +#include <linux/bug.h>
> > >
> > > /* sizeof(struct user) for AArch32 */
> > > #define COMPAT_USER_SZ 296
> > > @@ -119,6 +120,8 @@ struct pt_regs {
> > > u64 syscallno;
> > > };
> > >
> > > +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
> > > +
> > > #define arch_has_single_step() (1)
> > >
> > > #ifdef CONFIG_COMPAT
> > > @@ -147,6 +150,55 @@ struct pt_regs {
> > > #define user_stack_pointer(regs) \
> > > (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
> > >
> > > +extern int regs_query_register_offset(const char *name);
> > > +extern const char *regs_query_register_name(unsigned int offset);
> >
> > Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
> > these patches applied but couldn't find any use.
>
> It's referenced in kernel/trace/trace_probe.c.
I meant regs_query_register_name() (vim completion wrote the first one).
> > > +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
> >
> > This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> > make it static and remove the declaration?
>
> OK.
I can change it locally.
Are these going to be used in the future by uprobes?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
2016-07-08 16:35 ` David Long
@ 2016-07-15 16:47 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 16:47 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:50PM -0400, David Long wrote:
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
> * Exception vectors.
> */
>
> + .pushsection ".entry.text", "ax"
> .align 11
> ENTRY(vectors)
> ventry el1_sync_invalid // Synchronous EL1t
> @@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
> mov x0, sp
> b sys_rt_sigreturn
> ENDPROC(sys_rt_sigreturn_wrapper)
> +
> + .popsection
Does the above sigreturn wrapper need to be included in the .entry.text
section?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
@ 2016-07-15 16:47 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-15 16:47 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:50PM -0400, David Long wrote:
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
> * Exception vectors.
> */
>
> + .pushsection ".entry.text", "ax"
> .align 11
> ENTRY(vectors)
> ventry el1_sync_invalid // Synchronous EL1t
> @@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
> mov x0, sp
> b sys_rt_sigreturn
> ENDPROC(sys_rt_sigreturn_wrapper)
> +
> + .popsection
Does the above sigreturn wrapper need to be included in the .entry.text
section?
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-15 15:13 ` Catalin Marinas
@ 2016-07-15 17:51 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-15 17:51 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On 07/15/2016 11:13 AM, Catalin Marinas wrote:
> On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
>> On 07/15/2016 06:57 AM, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
>>>> --- a/arch/arm64/include/asm/ptrace.h
>>>> +++ b/arch/arm64/include/asm/ptrace.h
>>>> @@ -74,6 +74,7 @@
>>>> #define COMPAT_PT_DATA_ADDR 0x10004
>>>> #define COMPAT_PT_TEXT_END_ADDR 0x10008
>>>> #ifndef __ASSEMBLY__
>>>> +#include <linux/bug.h>
>>>>
>>>> /* sizeof(struct user) for AArch32 */
>>>> #define COMPAT_USER_SZ 296
>>>> @@ -119,6 +120,8 @@ struct pt_regs {
>>>> u64 syscallno;
>>>> };
>>>>
>>>> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
>>>> +
>>>> #define arch_has_single_step() (1)
>>>>
>>>> #ifdef CONFIG_COMPAT
>>>> @@ -147,6 +150,55 @@ struct pt_regs {
>>>> #define user_stack_pointer(regs) \
>>>> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>>>
>>>> +extern int regs_query_register_offset(const char *name);
>>>> +extern const char *regs_query_register_name(unsigned int offset);
>>>
>>> Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
>>> these patches applied but couldnperf_regs.c't find any use.
>>
>> It's referenced in kernel/trace/trace_probe.c.
>
> I meant regs_query_register_name() (vim completion wrote the first one).
>
I had assumed it was used by kgdb to provide human-readable register
names for debugger output, but apparently that is handled inside the
kgdb.c stub for each architecture. I can only assume this is currently
provided in all (or at least most) architectures because some code
outside the kernel tree needs (or used to need?) to be able to do the
reverse of regs_query_register_offset(). It's easy enough to remove
this, but that will make arm64 unlike the other architectures in its
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API support.
>>>> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
>>>
>>> This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
>>> make it static and remove the declaration?
>>
>> OK.
>
> I can change it locally.
It's looking like there will need to be another iteration of the patch
for a few small things anyway, although those changes could also be done
as subsequent improvements.
>
> Are these going to be used in the future by uprobes?
>
It would appear not.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-15 17:51 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-15 17:51 UTC (permalink / raw)
To: linux-arm-kernel
On 07/15/2016 11:13 AM, Catalin Marinas wrote:
> On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
>> On 07/15/2016 06:57 AM, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
>>>> --- a/arch/arm64/include/asm/ptrace.h
>>>> +++ b/arch/arm64/include/asm/ptrace.h
>>>> @@ -74,6 +74,7 @@
>>>> #define COMPAT_PT_DATA_ADDR 0x10004
>>>> #define COMPAT_PT_TEXT_END_ADDR 0x10008
>>>> #ifndef __ASSEMBLY__
>>>> +#include <linux/bug.h>
>>>>
>>>> /* sizeof(struct user) for AArch32 */
>>>> #define COMPAT_USER_SZ 296
>>>> @@ -119,6 +120,8 @@ struct pt_regs {
>>>> u64 syscallno;
>>>> };
>>>>
>>>> +#define MAX_REG_OFFSET offsetof(struct pt_regs, pstate)
>>>> +
>>>> #define arch_has_single_step() (1)
>>>>
>>>> #ifdef CONFIG_COMPAT
>>>> @@ -147,6 +150,55 @@ struct pt_regs {
>>>> #define user_stack_pointer(regs) \
>>>> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>>>
>>>> +extern int regs_query_register_offset(const char *name);
>>>> +extern const char *regs_query_register_name(unsigned int offset);
>>>
>>> Is regs_query_register_offset() used anywhere? I grep'ed the kernel with
>>> these patches applied but couldnperf_regs.c't find any use.
>>
>> It's referenced in kernel/trace/trace_probe.c.
>
> I meant regs_query_register_name() (vim completion wrote the first one).
>
I had assumed it was used by kgdb to provide human-readable register
names for debugger output, but apparently that is handled inside the
kgdb.c stub for each architecture. I can only assume this is currently
provided in all (or at least most) architectures because some code
outside the kernel tree needs (or used to need?) to be able to do the
reverse of regs_query_register_offset(). It's easy enough to remove
this, but that will make arm64 unlike the other architectures in its
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API support.
>>>> +extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
>>>
>>> This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
>>> make it static and remove the declaration?
>>
>> OK.
>
> I can change it locally.
It's looking like there will need to be another iteration of the patch
for a few small things anyway, although those changes could also be done
as subsequent improvements.
>
> Are these going to be used in the future by uprobes?
>
It would appear not.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
2016-07-15 16:47 ` Catalin Marinas
@ 2016-07-19 0:53 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 0:53 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/15/2016 12:47 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:50PM -0400, David Long wrote:
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
>> * Exception vectors.
>> */
>>
>> + .pushsection ".entry.text", "ax"
>> .align 11
>> ENTRY(vectors)
>> ventry el1_sync_invalid // Synchronous EL1t
>> @@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
>> mov x0, sp
>> b sys_rt_sigreturn
>> ENDPROC(sys_rt_sigreturn_wrapper)
>> +
>> + .popsection
>
> Does the above sigreturn wrapper need to be included in the .entry.text
> section?
>
Apparently not. It wouldn't make sense for that to be in entry.text when
sys_rt_sigreturn() isn't. I'll put that in the list of changes.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able
@ 2016-07-19 0:53 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 0:53 UTC (permalink / raw)
To: linux-arm-kernel
On 07/15/2016 12:47 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:50PM -0400, David Long wrote:
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -243,6 +243,7 @@ tsk .req x28 // current thread_info
>> * Exception vectors.
>> */
>>
>> + .pushsection ".entry.text", "ax"
>> .align 11
>> ENTRY(vectors)
>> ventry el1_sync_invalid // Synchronous EL1t
>> @@ -781,3 +782,5 @@ ENTRY(sys_rt_sigreturn_wrapper)
>> mov x0, sp
>> b sys_rt_sigreturn
>> ENDPROC(sys_rt_sigreturn_wrapper)
>> +
>> + .popsection
>
> Does the above sigreturn wrapper need to be included in the .entry.text
> section?
>
Apparently not. It wouldn't make sense for that to be in entry.text when
sys_rt_sigreturn() isn't. I'll put that in the list of changes.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
2016-07-08 16:35 ` David Long
@ 2016-07-19 13:46 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 13:46 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:52PM -0400, David Long wrote:
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
> @@ -0,0 +1,85 @@
> +/*
> + * trampoline entry and return code for kretprobes.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/asm-offsets.h>
> +#include <asm/assembler.h>
> +
> + .text
> +
> +.macro save_all_base_regs
> + stp x0, x1, [sp, #S_X0]
> + stp x2, x3, [sp, #S_X2]
> + stp x4, x5, [sp, #S_X4]
> + stp x6, x7, [sp, #S_X6]
> + stp x8, x9, [sp, #S_X8]
> + stp x10, x11, [sp, #S_X10]
> + stp x12, x13, [sp, #S_X12]
> + stp x14, x15, [sp, #S_X14]
> + stp x16, x17, [sp, #S_X16]
> + stp x18, x19, [sp, #S_X18]
> + stp x20, x21, [sp, #S_X20]
> + stp x22, x23, [sp, #S_X22]
> + stp x24, x25, [sp, #S_X24]
> + stp x26, x27, [sp, #S_X26]
> + stp x28, x29, [sp, #S_X28]
> + add x0, sp, #S_FRAME_SIZE
> + stp lr, x0, [sp, #S_LR]
> +/*
> + * Construct a useful saved PSTATE
> + */
> + mrs x0, nzcv
> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
> + mrs x1, daif
> + and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
I don't think you need the masking here, the mrs should return the
corresponding 4 bits.
> + orr x0, x0, x1
> + mrs x1, CurrentEL
> + and x1, x1, #(3 << 2)
> + orr x0, x1, x0
> + mrs x1, SPSel
> + and x1, x1, #1
Same here.
> + orr x0, x1, x0
> + str x0, [sp, #S_PSTATE]
> +.endm
How is this pstate used, other than the restoring of the condition flag
in the restore_all_base_regs macro? Does a kretprobes handler need
access to them?
Anyway, it's worth doing an stp xzr, x0, [sp, S_PC] so that we
initialise the pc in pt_regs.
> +
> +.macro restore_all_base_regs
> + ldr x0, [sp, #S_PSTATE]
> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
> + msr nzcv, x0
> + ldp x0, x1, [sp, #S_X0]
> + ldp x2, x3, [sp, #S_X2]
> + ldp x4, x5, [sp, #S_X4]
> + ldp x6, x7, [sp, #S_X6]
> + ldp x8, x9, [sp, #S_X8]
> + ldp x10, x11, [sp, #S_X10]
> + ldp x12, x13, [sp, #S_X12]
> + ldp x14, x15, [sp, #S_X14]
> + ldp x16, x17, [sp, #S_X16]
> + ldp x18, x19, [sp, #S_X18]
> + ldp x20, x21, [sp, #S_X20]
> + ldp x22, x23, [sp, #S_X22]
> + ldp x24, x25, [sp, #S_X24]
> + ldp x26, x27, [sp, #S_X26]
> + ldp x28, x29, [sp, #S_X28]
> +.endm
> +
> +ENTRY(kretprobe_trampoline)
> +
> + sub sp, sp, #S_FRAME_SIZE
> +
> + save_all_base_regs
> +
> + mov x0, sp
> + bl trampoline_probe_handler
> + /* Replace trampoline address in lr with actual
> + orig_ret_addr return address. */
> + mov lr, x0
> +
> + restore_all_base_regs
> +
> + add sp, sp, #S_FRAME_SIZE
> +
> + ret
> +
> +ENDPROC(kretprobe_trampoline)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
@ 2016-07-19 13:46 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 13:46 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:52PM -0400, David Long wrote:
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
> @@ -0,0 +1,85 @@
> +/*
> + * trampoline entry and return code for kretprobes.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/asm-offsets.h>
> +#include <asm/assembler.h>
> +
> + .text
> +
> +.macro save_all_base_regs
> + stp x0, x1, [sp, #S_X0]
> + stp x2, x3, [sp, #S_X2]
> + stp x4, x5, [sp, #S_X4]
> + stp x6, x7, [sp, #S_X6]
> + stp x8, x9, [sp, #S_X8]
> + stp x10, x11, [sp, #S_X10]
> + stp x12, x13, [sp, #S_X12]
> + stp x14, x15, [sp, #S_X14]
> + stp x16, x17, [sp, #S_X16]
> + stp x18, x19, [sp, #S_X18]
> + stp x20, x21, [sp, #S_X20]
> + stp x22, x23, [sp, #S_X22]
> + stp x24, x25, [sp, #S_X24]
> + stp x26, x27, [sp, #S_X26]
> + stp x28, x29, [sp, #S_X28]
> + add x0, sp, #S_FRAME_SIZE
> + stp lr, x0, [sp, #S_LR]
> +/*
> + * Construct a useful saved PSTATE
> + */
> + mrs x0, nzcv
> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
> + mrs x1, daif
> + and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
I don't think you need the masking here, the mrs should return the
corresponding 4 bits.
> + orr x0, x0, x1
> + mrs x1, CurrentEL
> + and x1, x1, #(3 << 2)
> + orr x0, x1, x0
> + mrs x1, SPSel
> + and x1, x1, #1
Same here.
> + orr x0, x1, x0
> + str x0, [sp, #S_PSTATE]
> +.endm
How is this pstate used, other than the restoring of the condition flag
in the restore_all_base_regs macro? Does a kretprobes handler need
access to them?
Anyway, it's worth doing an stp xzr, x0, [sp, S_PC] so that we
initialise the pc in pt_regs.
> +
> +.macro restore_all_base_regs
> + ldr x0, [sp, #S_PSTATE]
> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
> + msr nzcv, x0
> + ldp x0, x1, [sp, #S_X0]
> + ldp x2, x3, [sp, #S_X2]
> + ldp x4, x5, [sp, #S_X4]
> + ldp x6, x7, [sp, #S_X6]
> + ldp x8, x9, [sp, #S_X8]
> + ldp x10, x11, [sp, #S_X10]
> + ldp x12, x13, [sp, #S_X12]
> + ldp x14, x15, [sp, #S_X14]
> + ldp x16, x17, [sp, #S_X16]
> + ldp x18, x19, [sp, #S_X18]
> + ldp x20, x21, [sp, #S_X20]
> + ldp x22, x23, [sp, #S_X22]
> + ldp x24, x25, [sp, #S_X24]
> + ldp x26, x27, [sp, #S_X26]
> + ldp x28, x29, [sp, #S_X28]
> +.endm
> +
> +ENTRY(kretprobe_trampoline)
> +
> + sub sp, sp, #S_FRAME_SIZE
> +
> + save_all_base_regs
> +
> + mov x0, sp
> + bl trampoline_probe_handler
> + /* Replace trampoline address in lr with actual
> + orig_ret_addr return address. */
> + mov lr, x0
> +
> + restore_all_base_regs
> +
> + add sp, sp, #S_FRAME_SIZE
> +
> + ret
> +
> +ENDPROC(kretprobe_trampoline)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-14 16:22 ` Catalin Marinas
@ 2016-07-19 13:57 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 13:57 UTC (permalink / raw)
To: David Long
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Thu, Jul 14, 2016 at 05:22:08PM +0100, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> > David A. Long (3):
> > arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> > arm64: Add more test functions to insn.c
> > arm64: add conditional instruction simulation support
> >
> > Pratyush Anand (2):
> > arm64: Blacklist non-kprobe-able symbol
> > arm64: Treat all entry code as non-kprobe-able
> >
> > Sandeepa Prabhu (4):
> > arm64: Kprobes with single stepping support
> > arm64: kprobes instruction simulation support
> > arm64: Add kernel return probes support (kretprobes)
> > kprobes: Add arm64 case in kprobe example module
> >
> > William Cohen (1):
> > arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
FYI, we managed to track down the issue to two bugs in the arm64 kernel
boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
While not KVM specific, the pre-conditions were more likely when running
as a guest (receiving interrupts early on during boot, possibly because
of a slow-down in the booting process due to stage 2 page faulting
mechanism).
Will is going to post the fixes soon.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-19 13:57 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 13:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 14, 2016 at 05:22:08PM +0100, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> > David A. Long (3):
> > arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
> > arm64: Add more test functions to insn.c
> > arm64: add conditional instruction simulation support
> >
> > Pratyush Anand (2):
> > arm64: Blacklist non-kprobe-able symbol
> > arm64: Treat all entry code as non-kprobe-able
> >
> > Sandeepa Prabhu (4):
> > arm64: Kprobes with single stepping support
> > arm64: kprobes instruction simulation support
> > arm64: Add kernel return probes support (kretprobes)
> > kprobes: Add arm64 case in kprobe example module
> >
> > William Cohen (1):
> > arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/core branch an
> tried to run the resulting kernel in a guest (on a Juno platform using
> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
> the kernel fails to boot with lots of "Unexpected kernel single-step
> exception at EL1".
FYI, we managed to track down the issue to two bugs in the arm64 kernel
boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
While not KVM specific, the pre-conditions were more likely when running
as a guest (receiving interrupts early on during boot, possibly because
of a slow-down in the booting process due to stage 2 page faulting
mechanism).
Will is going to post the fixes soon.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-19 13:57 ` Catalin Marinas
@ 2016-07-19 14:01 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 14:01 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On 07/19/2016 09:57 AM, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 05:22:08PM +0100, Catalin Marinas wrote:
>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>> David A. Long (3):
>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>> arm64: Add more test functions to insn.c
>>> arm64: add conditional instruction simulation support
>>>
>>> Pratyush Anand (2):
>>> arm64: Blacklist non-kprobe-able symbol
>>> arm64: Treat all entry code as non-kprobe-able
>>>
>>> Sandeepa Prabhu (4):
>>> arm64: Kprobes with single stepping support
>>> arm64: kprobes instruction simulation support
>>> arm64: Add kernel return probes support (kretprobes)
>>> kprobes: Add arm64 case in kprobe example module
>>>
>>> William Cohen (1):
>>> arm64: Add trampoline code for kretprobes
>>
>> I applied these patches on top of the arm64 for-next/core branch an
>> tried to run the resulting kernel in a guest (on a Juno platform using
>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>> the kernel fails to boot with lots of "Unexpected kernel single-step
>> exception at EL1".
>
> FYI, we managed to track down the issue to two bugs in the arm64 kernel
> boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
> While not KVM specific, the pre-conditions were more likely when running
> as a guest (receiving interrupts early on during boot, possibly because
> of a slow-down in the booting process due to stage 2 page faulting
> mechanism).
>
> Will is going to post the fixes soon.
>
Excellent news.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-19 14:01 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 14:01 UTC (permalink / raw)
To: linux-arm-kernel
On 07/19/2016 09:57 AM, Catalin Marinas wrote:
> On Thu, Jul 14, 2016 at 05:22:08PM +0100, Catalin Marinas wrote:
>> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>>> David A. Long (3):
>>> arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
>>> arm64: Add more test functions to insn.c
>>> arm64: add conditional instruction simulation support
>>>
>>> Pratyush Anand (2):
>>> arm64: Blacklist non-kprobe-able symbol
>>> arm64: Treat all entry code as non-kprobe-able
>>>
>>> Sandeepa Prabhu (4):
>>> arm64: Kprobes with single stepping support
>>> arm64: kprobes instruction simulation support
>>> arm64: Add kernel return probes support (kretprobes)
>>> kprobes: Add arm64 case in kprobe example module
>>>
>>> William Cohen (1):
>>> arm64: Add trampoline code for kretprobes
>>
>> I applied these patches on top of the arm64 for-next/core branch an
>> tried to run the resulting kernel in a guest (on a Juno platform using
>> both kvmtool and qemu) with KPROBES_SANITY_TEST enabled. Unfortunately,
>> the kernel fails to boot with lots of "Unexpected kernel single-step
>> exception at EL1".
>
> FYI, we managed to track down the issue to two bugs in the arm64 kernel
> boot part, occasionally leaving the PSTATE.D bit set for kernel threads.
> While not KVM specific, the pre-conditions were more likely when running
> as a guest (receiving interrupts early on during boot, possibly because
> of a slow-down in the booting process due to stage 2 page faulting
> mechanism).
>
> Will is going to post the fixes soon.
>
Excellent news.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
2016-07-15 17:51 ` David Long
@ 2016-07-19 14:17 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 14:17 UTC (permalink / raw)
To: David Long
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Daniel Thompson, Huang Shijie,
Dave P Martin, Petr Mladek, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Fri, Jul 15, 2016 at 01:51:02PM -0400, David Long wrote:
> On 07/15/2016 11:13 AM, Catalin Marinas wrote:
> >On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
> >>On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> >>>On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> >>>>+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
> >>>
> >>>This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> >>>make it static and remove the declaration?
> >>
> >>OK.
> >
> >I can change it locally.
>
> It's looking like there will need to be another iteration of the patch for a
> few small things anyway, although those changes could also be done as
> subsequent improvements.
I've pushed the branch below with my fixups on this series. Please post
any minor changes you have as additional patches on top. Thanks.
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/kprobes
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
@ 2016-07-19 14:17 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 14:17 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 15, 2016 at 01:51:02PM -0400, David Long wrote:
> On 07/15/2016 11:13 AM, Catalin Marinas wrote:
> >On Fri, Jul 15, 2016 at 10:51:23AM -0400, David Long wrote:
> >>On 07/15/2016 06:57 AM, Catalin Marinas wrote:
> >>>On Fri, Jul 08, 2016 at 12:35:45PM -0400, David Long wrote:
> >>>>+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
> >>>
> >>>This one only seems to be used in arch/arm64/kernel/ptrace.c. Can we
> >>>make it static and remove the declaration?
> >>
> >>OK.
> >
> >I can change it locally.
>
> It's looking like there will need to be another iteration of the patch for a
> few small things anyway, although those changes could also be done as
> subsequent improvements.
I've pushed the branch below with my fixups on this series. Please post
any minor changes you have as additional patches on top. Thanks.
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/kprobes
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-08 16:35 ` David Long
@ 2016-07-19 18:27 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 18:27 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> From: "David A. Long" <dave.long@linaro.org>
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first seen in October 2013. This version attempts to address concerns
> raised by reviewers and also fixes problems discovered during testing.
>
> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
> and return probes(kretprobes) support for ARM64.
Some more errors with this patchset applied and CONFIG_NET_TCPPROBE
enabled (it's fine with this option disabled though). I boot on a Juno
with NFS over UDP and then try to ssh into it (hence establish the first
TCP connection):
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = ffff000008ceb000
[00000003] *pgd=00000009fff6d003, *pud=00000009fff6c003, *pmd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at enqueue_task_fair+0x818/0x1188
LR is at enqueue_task_fair+0x8a4/0x1188
pc : [<ffff0000080e73d8>] lr : [<ffff0000080e7464>] pstate: 600001c5
sp : ffff80097fec3a80
x29: ffff80097fec3a80 x28: 0000000000000001
x27: 00000000afb50401 x26: afb504000afb5041
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000008bcbd90 x22: 0000000000000001
x21: ffff800975951900 x20: ffff800975951800
x19: ffff80097fec96e8 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000001 x14: 0000000000000001
x13: 0000000005da2e6c x12: 000000000044ab8d
x11: 0000000000000000 x10: 0000000000000001
x9 : 0000000000000000 x8 : 0000000991653ffc
x7 : 000000000000003e x6 : ffff80097fec9740
x5 : 0000000000000000 x4 : ffff0000087ef950
x3 : 0000000000000400 x2 : 000000000000005e
x1 : ffff80097fec9680 x0 : 0000000000000003
Process swapper/1 (pid: 0, stack limit = 0xffff800976910020)
Stack: (0xffff80097fec3a80 to 0xffff800976914000)
Call trace:
Exception stack(0xffff80097fec38c0 to 0xffff80097fec39e0)
38c0: ffff80097fec96e8 ffff800975951800 ffff80097fec3a80 ffff0000080e73d8
38e0: ffff800976ad2300 ffff800974a07e00 0000000000000003 ffff800974a00000
3900: 0000000000000000 ffff7e0025d28000 0000000000000013 0000000080010400
3920: ffff000008c9f000 0000000000000003 0000000100000000 000000000000000e
3940: ffff80097fec39a0 ffff0000081ae954 0000000000000000 0000000000000000
3960: 0000000000000003 ffff80097fec9680 000000000000005e 0000000000000400
3980: ffff0000087ef950 0000000000000000 ffff80097fec9740 000000000000003e
39a0: 0000000991653ffc 0000000000000000 0000000000000001 0000000000000000
39c0: 000000000044ab8d 0000000005da2e6c 0000000000000001 0000000000000001
[<ffff0000080e73d8>] enqueue_task_fair+0x818/0x1188
[<ffff0000080dbdd4>] activate_task+0x5c/0xa0
[<ffff0000080dc088>] ttwu_do_activate+0x50/0x88
[<ffff0000080dda60>] try_to_wake_up+0x228/0x2c0
[<ffff0000080ddbd0>] default_wake_function+0x10/0x18
[<ffff0000080f0ffc>] autoremove_wake_function+0x14/0x40
[<ffff0000080f0814>] __wake_up_common+0x5c/0xa0
[<ffff0000080f0e64>] __wake_up_sync_key+0x4c/0x78
[<ffff00000875a330>] tcp_prequeue+0x190/0x2e8
[<ffff00000875b8a4>] tcp_v4_rcv+0xa5c/0xb08
[<ffff000008736eac>] ip_local_deliver+0xa4/0x200
[<ffff0000087373e4>] ip_rcv+0x3dc/0x5f0
[<ffff000008707460>] __netif_receive_skb_core+0x5f8/0x7c8
[<ffff000008709990>] __netif_receive_skb+0x18/0x68
[<ffff000008709a04>] netif_receive_skb_internal+0x24/0xa8
[<ffff000008709a94>] netif_receive_skb+0xc/0x18
[<ffff00000858f9b0>] smsc911x_poll+0xf0/0x278
[<ffff00000870b0b0>] net_rx_action+0x1d8/0x2b0
[<ffff0000080be200>] __do_softirq+0x100/0x210
[<ffff0000080be5b8>] irq_exit+0x90/0xd8
[<ffff0000080fb2f8>] __handle_domain_irq+0x60/0xb8
[<ffff000008081578>] gic_handle_irq+0x58/0xb0
Exception stack(0xffff800976913df0 to 0xffff800976913f10)
3de0: 0000000000000000 ffff80097fec9680
3e00: 00008009772f9000 0000000002800000 0000000000000004 000000000115c074
3e20: 0000000000000015 000000000000012f 000000000000016d ffff80097fec872c
3e40: 0000000000000a12 0000000000000a12 071c71c71c71c71c 20230a2e746c7561
3e60: 524150203a4c4c41 0000000000000000 0000000000000000 0000000000000000
3e80: 0000000000000000 00000009972f2718 ffff8009763d7400 0000000000000000
3ea0: 0000000000000000 ffff000008c6bb20 00000009972ada50 ffff000008c05c1c
3ec0: ffff000008c05000 ffff000008c6bb20 ffff800976910000 ffff800976913f10
3ee0: ffff00000864ac08 ffff800976913f10 ffff00000864ac0c 0000000060000145
3f00: ffff000008c6bb20 ffff8009763d7400
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000864ac0c>] cpuidle_enter_state+0x1b4/0x238
[<ffff00000864acc8>] cpuidle_enter+0x18/0x20
[<ffff0000080f15c0>] call_cpuidle+0x18/0x30
[<ffff0000080f1838>] cpu_startup_entry+0x198/0x1f8
[<ffff00000808dc78>] secondary_start_kernel+0x158/0x198
[<00000000800831a8>] 0x800831a8
Code: f8606ae0 b4ffe5c0 f9447023 f9403e62 (f9400006)
Bad mode in Synchronous Abort handler detected on CPU1, code 0x8600000f -- IABT (current EL)
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at 0xffff80097fec3f40
LR is at irq_work_run_list+0x68/0xb8
pc : [<ffff80097fec3f40>] lr : [<ffff000008147978>] pstate: 000001c5
sp : ffff80097fec35f0
x29: ffff80097fec35f0 x28: ffff800976910000
x27: 00000000afb50401 x26: afb504000afb5041
x25: ffff80097fec0000 x24: ffff800976901900
x23: ffff000008005000 x22: 0000000000000000
x21: ffff000008ca0d53 x20: ffff000008ca0d52
x19: ffff80097fec4da8 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000000
x15: ffff000008cacc95 x14: 3431303030303630
x13: ffff000008caf0aa x12: 0000000005f5e0ff
x11: 000000000000016d x10: 00000000000a3d60
x9 : ffff80097fec3480 x8 : 000000000000016e
x7 : 6628203236653330 x6 : 000000000000000a
x5 : ffff80097fec4da0 x4 : 00008009772f9000
x3 : ffff80097fec3f51 x2 : 0000000000000000
x1 : ffff80097fec3f40 x0 : ffff80097fec4da0
Internal error: Oops - bad mode: 0 [#2] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at 0xffff80097fec3f40
LR is at irq_work_run_list+0x68/0xb8
pc : [<ffff80097fec3f40>] lr : [<ffff000008147978>] pstate: 000001c5
sp : ffff80097fec35f0
x29: ffff80097fec35f0 x28: ffff800976910000
x27: 00000000afb50401 x26: afb504000afb5041
x25: ffff80097fec0000 x24: ffff800976901900
x23: ffff000008005000 x22: 0000000000000000
x21: ffff000008ca0d53 x20: ffff000008ca0d52
x19: ffff80097fec4da8 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000000
x15: ffff000008cacc95 x14: 3431303030303630
x13: ffff000008caf0aa x12: 0000000005f5e0ff
x11: 000000000000016d x10: 00000000000a3d60
x9 : ffff80097fec3480 x8 : 000000000000016e
x7 : 6628203236653330 x6 : 000000000000000a
x5 : ffff80097fec4da0 x4 : 00008009772f9000
x3 : ffff80097fec3f51 x2 : 0000000000000000
x1 : ffff80097fec3f40 x0 : ffff80097fec4da0
Process swapper/1 (pid: 0, stack limit = 0xffff800976910020)
Stack: (0xffff80097fec35f0 to 0xffff800976914000)
Call trace:
[<ffff80097fec3f40>] 0xffff80097fec3f40
[<ffff0000081479ec>] irq_work_run+0x24/0x40
[<ffff00000808e208>] handle_IPI+0x148/0x168
[<ffff0000080815b0>] gic_handle_irq+0x90/0xb0
Exception stack(0xffff80097fec3680 to 0xffff80097fec37a0)
3680: ffff80097fec36b0 ffff80097fec3960 ffff80097fec37d0 ffff0000087d0468
36a0: 0000000060000145 ffff80097fec3720 ffff000008ca70e8 0000000000000001
36c0: 0000000000000080 0000000000000080 0000000000000000 ffff80097fec4da0
36e0: 000000000000000a 6628203236653330 000000000000016e ffff80097fec3480
3700: 00000000000a3d60 000000000000016d 0000000005f5e0ff ffff000008caf0aa
3720: 3431303030303630 ffff000008cacc95 0000000000000000 0000000000000000
3740: 0000000000000006 ffff000008ca7000 ffff80097fec3960 0000000000000000
3760: ffff0000089fd908 ffff800976910000 ffff800976901900 0000000000000000
3780: afb504000afb5041 00000000afb50401 0000000000000001 ffff80097fec37d0
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000809800c>] __do_kernel_fault.part.1+0x74/0x88
[<ffff0000087d277c>] do_page_fault+0x37c/0x380
[<ffff0000087d27c4>] do_translation_fault+0x44/0x50
[<ffff00000808137c>] do_mem_abort+0x44/0xa0
Exception stack(0xffff80097fec38c0 to 0xffff80097fec39e0)
38c0: ffff80097fec96e8 ffff800975951800 ffff80097fec3a80 ffff0000080e73d8
38e0: ffff800976ad2300 ffff800974a07e00 0000000000000003 ffff800974a00000
3900: 0000000000000000 ffff7e0025d28000 0000000000000013 0000000080010400
3920: ffff000008c9f000 0000000000000003 0000000100000000 000000000000000e
3940: ffff80097fec39a0 ffff0000081ae954 0000000000000000 0000000000000000
3960: 0000000000000003 ffff80097fec9680 000000000000005e 0000000000000400
3980: ffff0000087ef950 0000000000000000 ffff80097fec9740 000000000000003e
39a0: 0000000991653ffc 0000000000000000 0000000000000001 0000000000000000
39c0: 000000000044ab8d 0000000005da2e6c 0000000000000001 0000000000000001
[<ffff000008082568>] el1_da+0x18/0x70
[<ffff0000080dbdd4>] activate_task+0x5c/0xa0
[<ffff0000080dc088>] ttwu_do_activate+0x50/0x88
[<ffff0000080dda60>] try_to_wake_up+0x228/0x2c0
[<ffff0000080ddbd0>] default_wake_function+0x10/0x18
[<ffff0000080f0ffc>] autoremove_wake_function+0x14/0x40
[<ffff0000080f0814>] __wake_up_common+0x5c/0xa0
[<ffff0000080f0e64>] __wake_up_sync_key+0x4c/0x78
[<ffff00000875a330>] tcp_prequeue+0x190/0x2e8
[<ffff00000875b8a4>] tcp_v4_rcv+0xa5c/0xb08
[<ffff000008736eac>] ip_local_deliver+0xa4/0x200
[<ffff0000087373e4>] ip_rcv+0x3dc/0x5f0
[<ffff000008707460>] __netif_receive_skb_core+0x5f8/0x7c8
[<ffff000008709990>] __netif_receive_skb+0x18/0x68
[<ffff000008709a04>] netif_receive_skb_internal+0x24/0xa8
[<ffff000008709a94>] netif_receive_skb+0xc/0x18
[<ffff00000858f9b0>] smsc911x_poll+0xf0/0x278
[<ffff00000870b0b0>] net_rx_action+0x1d8/0x2b0
[<ffff0000080be200>] __do_softirq+0x100/0x210
[<ffff0000080be5b8>] irq_exit+0x90/0xd8
[<ffff0000080fb2f8>] __handle_domain_irq+0x60/0xb8
[<ffff000008081578>] gic_handle_irq+0x58/0xb0
Exception stack(0xffff800976913df0 to 0xffff800976913f10)
3de0: 0000000000000000 ffff80097fec9680
3e00: 00008009772f9000 0000000002800000 0000000000000004 000000000115c074
3e20: 0000000000000015 000000000000012f 000000000000016d ffff80097fec872c
3e40: 0000000000000a12 0000000000000a12 071c71c71c71c71c 20230a2e746c7561
3e60: 524150203a4c4c41 0000000000000000 0000000000000000 0000000000000000
3e80: 0000000000000000 00000009972f2718 ffff8009763d7400 0000000000000000
3ea0: 0000000000000000 ffff000008c6bb20 00000009972ada50 ffff000008c05c1c
3ec0: ffff000008c05000 ffff000008c6bb20 ffff800976910000 ffff800976913f10
3ee0: ffff00000864ac08 ffff800976913f10 ffff00000864ac0c 0000000060000145
3f00: ffff000008c6bb20 ffff8009763d7400
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000864ac0c>] cpuidle_enter_state+0x1b4/0x238
[<ffff00000864acc8>] cpuidle_enter+0x18/0x20
[<ffff0000080f15c0>] call_cpuidle+0x18/0x30
[<ffff0000080f1838>] cpu_startup_entry+0x198/0x1f8
[<ffff00000808dc78>] secondary_start_kernel+0x158/0x198
[<00000000800831a8>] 0x800831a8
Code: 08aa2d08 ffff0000 08ca0d50 ffff0000 (7fec3f40)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-19 18:27 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-19 18:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> From: "David A. Long" <dave.long@linaro.org>
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first seen in October 2013. This version attempts to address concerns
> raised by reviewers and also fixes problems discovered during testing.
>
> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
> and return probes(kretprobes) support for ARM64.
Some more errors with this patchset applied and CONFIG_NET_TCPPROBE
enabled (it's fine with this option disabled though). I boot on a Juno
with NFS over UDP and then try to ssh into it (hence establish the first
TCP connection):
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = ffff000008ceb000
[00000003] *pgd=00000009fff6d003, *pud=00000009fff6c003, *pmd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at enqueue_task_fair+0x818/0x1188
LR is at enqueue_task_fair+0x8a4/0x1188
pc : [<ffff0000080e73d8>] lr : [<ffff0000080e7464>] pstate: 600001c5
sp : ffff80097fec3a80
x29: ffff80097fec3a80 x28: 0000000000000001
x27: 00000000afb50401 x26: afb504000afb5041
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000008bcbd90 x22: 0000000000000001
x21: ffff800975951900 x20: ffff800975951800
x19: ffff80097fec96e8 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000001 x14: 0000000000000001
x13: 0000000005da2e6c x12: 000000000044ab8d
x11: 0000000000000000 x10: 0000000000000001
x9 : 0000000000000000 x8 : 0000000991653ffc
x7 : 000000000000003e x6 : ffff80097fec9740
x5 : 0000000000000000 x4 : ffff0000087ef950
x3 : 0000000000000400 x2 : 000000000000005e
x1 : ffff80097fec9680 x0 : 0000000000000003
Process swapper/1 (pid: 0, stack limit = 0xffff800976910020)
Stack: (0xffff80097fec3a80 to 0xffff800976914000)
Call trace:
Exception stack(0xffff80097fec38c0 to 0xffff80097fec39e0)
38c0: ffff80097fec96e8 ffff800975951800 ffff80097fec3a80 ffff0000080e73d8
38e0: ffff800976ad2300 ffff800974a07e00 0000000000000003 ffff800974a00000
3900: 0000000000000000 ffff7e0025d28000 0000000000000013 0000000080010400
3920: ffff000008c9f000 0000000000000003 0000000100000000 000000000000000e
3940: ffff80097fec39a0 ffff0000081ae954 0000000000000000 0000000000000000
3960: 0000000000000003 ffff80097fec9680 000000000000005e 0000000000000400
3980: ffff0000087ef950 0000000000000000 ffff80097fec9740 000000000000003e
39a0: 0000000991653ffc 0000000000000000 0000000000000001 0000000000000000
39c0: 000000000044ab8d 0000000005da2e6c 0000000000000001 0000000000000001
[<ffff0000080e73d8>] enqueue_task_fair+0x818/0x1188
[<ffff0000080dbdd4>] activate_task+0x5c/0xa0
[<ffff0000080dc088>] ttwu_do_activate+0x50/0x88
[<ffff0000080dda60>] try_to_wake_up+0x228/0x2c0
[<ffff0000080ddbd0>] default_wake_function+0x10/0x18
[<ffff0000080f0ffc>] autoremove_wake_function+0x14/0x40
[<ffff0000080f0814>] __wake_up_common+0x5c/0xa0
[<ffff0000080f0e64>] __wake_up_sync_key+0x4c/0x78
[<ffff00000875a330>] tcp_prequeue+0x190/0x2e8
[<ffff00000875b8a4>] tcp_v4_rcv+0xa5c/0xb08
[<ffff000008736eac>] ip_local_deliver+0xa4/0x200
[<ffff0000087373e4>] ip_rcv+0x3dc/0x5f0
[<ffff000008707460>] __netif_receive_skb_core+0x5f8/0x7c8
[<ffff000008709990>] __netif_receive_skb+0x18/0x68
[<ffff000008709a04>] netif_receive_skb_internal+0x24/0xa8
[<ffff000008709a94>] netif_receive_skb+0xc/0x18
[<ffff00000858f9b0>] smsc911x_poll+0xf0/0x278
[<ffff00000870b0b0>] net_rx_action+0x1d8/0x2b0
[<ffff0000080be200>] __do_softirq+0x100/0x210
[<ffff0000080be5b8>] irq_exit+0x90/0xd8
[<ffff0000080fb2f8>] __handle_domain_irq+0x60/0xb8
[<ffff000008081578>] gic_handle_irq+0x58/0xb0
Exception stack(0xffff800976913df0 to 0xffff800976913f10)
3de0: 0000000000000000 ffff80097fec9680
3e00: 00008009772f9000 0000000002800000 0000000000000004 000000000115c074
3e20: 0000000000000015 000000000000012f 000000000000016d ffff80097fec872c
3e40: 0000000000000a12 0000000000000a12 071c71c71c71c71c 20230a2e746c7561
3e60: 524150203a4c4c41 0000000000000000 0000000000000000 0000000000000000
3e80: 0000000000000000 00000009972f2718 ffff8009763d7400 0000000000000000
3ea0: 0000000000000000 ffff000008c6bb20 00000009972ada50 ffff000008c05c1c
3ec0: ffff000008c05000 ffff000008c6bb20 ffff800976910000 ffff800976913f10
3ee0: ffff00000864ac08 ffff800976913f10 ffff00000864ac0c 0000000060000145
3f00: ffff000008c6bb20 ffff8009763d7400
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000864ac0c>] cpuidle_enter_state+0x1b4/0x238
[<ffff00000864acc8>] cpuidle_enter+0x18/0x20
[<ffff0000080f15c0>] call_cpuidle+0x18/0x30
[<ffff0000080f1838>] cpu_startup_entry+0x198/0x1f8
[<ffff00000808dc78>] secondary_start_kernel+0x158/0x198
[<00000000800831a8>] 0x800831a8
Code: f8606ae0 b4ffe5c0 f9447023 f9403e62 (f9400006)
Bad mode in Synchronous Abort handler detected on CPU1, code 0x8600000f -- IABT (current EL)
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at 0xffff80097fec3f40
LR is at irq_work_run_list+0x68/0xb8
pc : [<ffff80097fec3f40>] lr : [<ffff000008147978>] pstate: 000001c5
sp : ffff80097fec35f0
x29: ffff80097fec35f0 x28: ffff800976910000
x27: 00000000afb50401 x26: afb504000afb5041
x25: ffff80097fec0000 x24: ffff800976901900
x23: ffff000008005000 x22: 0000000000000000
x21: ffff000008ca0d53 x20: ffff000008ca0d52
x19: ffff80097fec4da8 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000000
x15: ffff000008cacc95 x14: 3431303030303630
x13: ffff000008caf0aa x12: 0000000005f5e0ff
x11: 000000000000016d x10: 00000000000a3d60
x9 : ffff80097fec3480 x8 : 000000000000016e
x7 : 6628203236653330 x6 : 000000000000000a
x5 : ffff80097fec4da0 x4 : 00008009772f9000
x3 : ffff80097fec3f51 x2 : 0000000000000000
x1 : ffff80097fec3f40 x0 : ffff80097fec4da0
Internal error: Oops - bad mode: 0 [#2] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.7.0-rc4+ #9
Hardware name: ARM Juno development board (r0) (DT)
task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
PC is at 0xffff80097fec3f40
LR is at irq_work_run_list+0x68/0xb8
pc : [<ffff80097fec3f40>] lr : [<ffff000008147978>] pstate: 000001c5
sp : ffff80097fec35f0
x29: ffff80097fec35f0 x28: ffff800976910000
x27: 00000000afb50401 x26: afb504000afb5041
x25: ffff80097fec0000 x24: ffff800976901900
x23: ffff000008005000 x22: 0000000000000000
x21: ffff000008ca0d53 x20: ffff000008ca0d52
x19: ffff80097fec4da8 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000000
x15: ffff000008cacc95 x14: 3431303030303630
x13: ffff000008caf0aa x12: 0000000005f5e0ff
x11: 000000000000016d x10: 00000000000a3d60
x9 : ffff80097fec3480 x8 : 000000000000016e
x7 : 6628203236653330 x6 : 000000000000000a
x5 : ffff80097fec4da0 x4 : 00008009772f9000
x3 : ffff80097fec3f51 x2 : 0000000000000000
x1 : ffff80097fec3f40 x0 : ffff80097fec4da0
Process swapper/1 (pid: 0, stack limit = 0xffff800976910020)
Stack: (0xffff80097fec35f0 to 0xffff800976914000)
Call trace:
[<ffff80097fec3f40>] 0xffff80097fec3f40
[<ffff0000081479ec>] irq_work_run+0x24/0x40
[<ffff00000808e208>] handle_IPI+0x148/0x168
[<ffff0000080815b0>] gic_handle_irq+0x90/0xb0
Exception stack(0xffff80097fec3680 to 0xffff80097fec37a0)
3680: ffff80097fec36b0 ffff80097fec3960 ffff80097fec37d0 ffff0000087d0468
36a0: 0000000060000145 ffff80097fec3720 ffff000008ca70e8 0000000000000001
36c0: 0000000000000080 0000000000000080 0000000000000000 ffff80097fec4da0
36e0: 000000000000000a 6628203236653330 000000000000016e ffff80097fec3480
3700: 00000000000a3d60 000000000000016d 0000000005f5e0ff ffff000008caf0aa
3720: 3431303030303630 ffff000008cacc95 0000000000000000 0000000000000000
3740: 0000000000000006 ffff000008ca7000 ffff80097fec3960 0000000000000000
3760: ffff0000089fd908 ffff800976910000 ffff800976901900 0000000000000000
3780: afb504000afb5041 00000000afb50401 0000000000000001 ffff80097fec37d0
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000809800c>] __do_kernel_fault.part.1+0x74/0x88
[<ffff0000087d277c>] do_page_fault+0x37c/0x380
[<ffff0000087d27c4>] do_translation_fault+0x44/0x50
[<ffff00000808137c>] do_mem_abort+0x44/0xa0
Exception stack(0xffff80097fec38c0 to 0xffff80097fec39e0)
38c0: ffff80097fec96e8 ffff800975951800 ffff80097fec3a80 ffff0000080e73d8
38e0: ffff800976ad2300 ffff800974a07e00 0000000000000003 ffff800974a00000
3900: 0000000000000000 ffff7e0025d28000 0000000000000013 0000000080010400
3920: ffff000008c9f000 0000000000000003 0000000100000000 000000000000000e
3940: ffff80097fec39a0 ffff0000081ae954 0000000000000000 0000000000000000
3960: 0000000000000003 ffff80097fec9680 000000000000005e 0000000000000400
3980: ffff0000087ef950 0000000000000000 ffff80097fec9740 000000000000003e
39a0: 0000000991653ffc 0000000000000000 0000000000000001 0000000000000000
39c0: 000000000044ab8d 0000000005da2e6c 0000000000000001 0000000000000001
[<ffff000008082568>] el1_da+0x18/0x70
[<ffff0000080dbdd4>] activate_task+0x5c/0xa0
[<ffff0000080dc088>] ttwu_do_activate+0x50/0x88
[<ffff0000080dda60>] try_to_wake_up+0x228/0x2c0
[<ffff0000080ddbd0>] default_wake_function+0x10/0x18
[<ffff0000080f0ffc>] autoremove_wake_function+0x14/0x40
[<ffff0000080f0814>] __wake_up_common+0x5c/0xa0
[<ffff0000080f0e64>] __wake_up_sync_key+0x4c/0x78
[<ffff00000875a330>] tcp_prequeue+0x190/0x2e8
[<ffff00000875b8a4>] tcp_v4_rcv+0xa5c/0xb08
[<ffff000008736eac>] ip_local_deliver+0xa4/0x200
[<ffff0000087373e4>] ip_rcv+0x3dc/0x5f0
[<ffff000008707460>] __netif_receive_skb_core+0x5f8/0x7c8
[<ffff000008709990>] __netif_receive_skb+0x18/0x68
[<ffff000008709a04>] netif_receive_skb_internal+0x24/0xa8
[<ffff000008709a94>] netif_receive_skb+0xc/0x18
[<ffff00000858f9b0>] smsc911x_poll+0xf0/0x278
[<ffff00000870b0b0>] net_rx_action+0x1d8/0x2b0
[<ffff0000080be200>] __do_softirq+0x100/0x210
[<ffff0000080be5b8>] irq_exit+0x90/0xd8
[<ffff0000080fb2f8>] __handle_domain_irq+0x60/0xb8
[<ffff000008081578>] gic_handle_irq+0x58/0xb0
Exception stack(0xffff800976913df0 to 0xffff800976913f10)
3de0: 0000000000000000 ffff80097fec9680
3e00: 00008009772f9000 0000000002800000 0000000000000004 000000000115c074
3e20: 0000000000000015 000000000000012f 000000000000016d ffff80097fec872c
3e40: 0000000000000a12 0000000000000a12 071c71c71c71c71c 20230a2e746c7561
3e60: 524150203a4c4c41 0000000000000000 0000000000000000 0000000000000000
3e80: 0000000000000000 00000009972f2718 ffff8009763d7400 0000000000000000
3ea0: 0000000000000000 ffff000008c6bb20 00000009972ada50 ffff000008c05c1c
3ec0: ffff000008c05000 ffff000008c6bb20 ffff800976910000 ffff800976913f10
3ee0: ffff00000864ac08 ffff800976913f10 ffff00000864ac0c 0000000060000145
3f00: ffff000008c6bb20 ffff8009763d7400
[<ffff000008082720>] el1_irq+0xa0/0x10c
[<ffff00000864ac0c>] cpuidle_enter_state+0x1b4/0x238
[<ffff00000864acc8>] cpuidle_enter+0x18/0x20
[<ffff0000080f15c0>] call_cpuidle+0x18/0x30
[<ffff0000080f1838>] cpu_startup_entry+0x198/0x1f8
[<ffff00000808dc78>] secondary_start_kernel+0x158/0x198
[<00000000800831a8>] 0x800831a8
Code: 08aa2d08 ffff0000 08ca0d50 ffff0000 (7fec3f40)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
2016-07-19 18:27 ` Catalin Marinas
@ 2016-07-19 19:38 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 19:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/19/2016 02:27 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first seen in October 2013. This version attempts to address concerns
>> raised by reviewers and also fixes problems discovered during testing.
>>
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>
> Some more errors with this patchset applied and CONFIG_NET_TCPPROBE
> enabled (it's fine with this option disabled though). I boot on a Juno
> with NFS over UDP and then try to ssh into it (hence establish the first
> TCP connection):
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = ffff000008ceb000
> [00000003] *pgd=00000009fff6d003, *pud=00000009fff6c003, *pmd=0000000000000000
> Internal error: Oops: 96000004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.0-rc4+ #9
> Hardware name: ARM Juno development board (r0) (DT)
> task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
> PC is at enqueue_task_fair+0x818/0x1188
> LR is at enqueue_task_fair+0x8a4/0x1188
> pc : [<ffff0000080e73d8>] lr : [<ffff0000080e7464>] pstate: 600001c5
> sp : ffff80097fec3a80
[...]
I've reproduced the failure on hikey. I'm looking at it.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support
@ 2016-07-19 19:38 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-19 19:38 UTC (permalink / raw)
To: linux-arm-kernel
On 07/19/2016 02:27 PM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first seen in October 2013. This version attempts to address concerns
>> raised by reviewers and also fixes problems discovered during testing.
>>
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>
> Some more errors with this patchset applied and CONFIG_NET_TCPPROBE
> enabled (it's fine with this option disabled though). I boot on a Juno
> with NFS over UDP and then try to ssh into it (hence establish the first
> TCP connection):
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = ffff000008ceb000
> [00000003] *pgd=00000009fff6d003, *pud=00000009fff6c003, *pmd=0000000000000000
> Internal error: Oops: 96000004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.7.0-rc4+ #9
> Hardware name: ARM Juno development board (r0) (DT)
> task: ffff800976901900 ti: ffff800976910000 task.ti: ffff800976910000
> PC is at enqueue_task_fair+0x818/0x1188
> LR is at enqueue_task_fair+0x8a4/0x1188
> pc : [<ffff0000080e73d8>] lr : [<ffff0000080e7464>] pstate: 600001c5
> sp : ffff80097fec3a80
[...]
I've reproduced the failure on hikey. I'm looking at it.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-08 16:35 ` David Long
@ 2016-07-20 9:36 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 9:36 UTC (permalink / raw)
To: David Long, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 08/07/16 17:35, David Long wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
>
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.
>
> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
> kprobe, e.g.: during kprobes reenter so that probed instruction can be
> single stepped within the kprobe handler -exception- context.
> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
> any further re-entry is prevented by not calling handlers and the case
> counted as a missed kprobe).
>
> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
> like branching and symbolic literals access as the offset from the new PC
> (slot address) may not be ensured to fit in the immediate value of
> the opcode. Such instructions need simulation, so reject
> probing them.
>
> Instructions generating exceptions or cpu mode change are rejected
> for probing.
>
> Exclusive load/store instructions are rejected too. Additionally, the
> code is checked to see if it is inside an exclusive load/store sequence
> (code from Pratyush).
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> This also changes arch/arm64/include/asm/ptrace.h to use
> include/asm-generic/ptrace.h.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
[...]
> +void __kprobes jprobe_return(void)
> +{
> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> +
> + /*
> + * Jprobe handler return by entering break exception,
> + * encoded same as kprobe, but with following conditions
> + * -a magic number in x0 to identify from rest of other kprobes.
> + * -restore stack addr to original saved pt_regs
> + */
> + asm volatile ("ldr x0, [%0]\n\t"
> + "mov sp, x0\n\t"
> + ".globl jprobe_return_break\n\t"
> + "jprobe_return_break:\n\t"
> + "brk %1\n\t"
> + :
> + : "r"(&kcb->jprobe_saved_regs.sp),
> + "I"(BRK64_ESR_KPROBES)
> + : "memory");
A couple of remarks here:
- the comment seems wrong, as you load the stack pointer in X0, nothing
else, and seem to identify the jprobe by looking at the PC, not X0.
- using explicit registers is really ugly. How about something like this
instead:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index c89811d..823cf92 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
* -a magic number in x0 to identify from rest of other kprobes.
* -restore stack addr to original saved pt_regs
*/
- asm volatile ("ldr x0, [%0]\n\t"
- "mov sp, x0\n\t"
+ asm volatile ("mov sp, %0\n\t"
".globl jprobe_return_break\n\t"
"jprobe_return_break:\n\t"
"brk %1\n\t"
:
- : "r"(&kcb->jprobe_saved_regs.sp),
+ : "r" (kcb->jprobe_saved_regs.sp),
"I"(BRK64_ESR_KPROBES)
: "memory");
}
though hijacking SP in the middle of a C function still feels pretty fragile.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 9:36 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 9:36 UTC (permalink / raw)
To: linux-arm-kernel
On 08/07/16 17:35, David Long wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
>
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.
>
> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
> kprobe, e.g.: during kprobes reenter so that probed instruction can be
> single stepped within the kprobe handler -exception- context.
> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
> any further re-entry is prevented by not calling handlers and the case
> counted as a missed kprobe).
>
> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
> like branching and symbolic literals access as the offset from the new PC
> (slot address) may not be ensured to fit in the immediate value of
> the opcode. Such instructions need simulation, so reject
> probing them.
>
> Instructions generating exceptions or cpu mode change are rejected
> for probing.
>
> Exclusive load/store instructions are rejected too. Additionally, the
> code is checked to see if it is inside an exclusive load/store sequence
> (code from Pratyush).
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> This also changes arch/arm64/include/asm/ptrace.h to use
> include/asm-generic/ptrace.h.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
[...]
> +void __kprobes jprobe_return(void)
> +{
> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> +
> + /*
> + * Jprobe handler return by entering break exception,
> + * encoded same as kprobe, but with following conditions
> + * -a magic number in x0 to identify from rest of other kprobes.
> + * -restore stack addr to original saved pt_regs
> + */
> + asm volatile ("ldr x0, [%0]\n\t"
> + "mov sp, x0\n\t"
> + ".globl jprobe_return_break\n\t"
> + "jprobe_return_break:\n\t"
> + "brk %1\n\t"
> + :
> + : "r"(&kcb->jprobe_saved_regs.sp),
> + "I"(BRK64_ESR_KPROBES)
> + : "memory");
A couple of remarks here:
- the comment seems wrong, as you load the stack pointer in X0, nothing
else, and seem to identify the jprobe by looking at the PC, not X0.
- using explicit registers is really ugly. How about something like this
instead:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index c89811d..823cf92 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
* -a magic number in x0 to identify from rest of other kprobes.
* -restore stack addr to original saved pt_regs
*/
- asm volatile ("ldr x0, [%0]\n\t"
- "mov sp, x0\n\t"
+ asm volatile ("mov sp, %0\n\t"
".globl jprobe_return_break\n\t"
"jprobe_return_break:\n\t"
"brk %1\n\t"
:
- : "r"(&kcb->jprobe_saved_regs.sp),
+ : "r" (kcb->jprobe_saved_regs.sp),
"I"(BRK64_ESR_KPROBES)
: "memory");
}
though hijacking SP in the middle of a C function still feels pretty fragile.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 9:36 ` Marc Zyngier
@ 2016-07-20 11:16 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 11:16 UTC (permalink / raw)
To: Marc Zyngier
Cc: David Long, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Wed, Jul 20, 2016 at 10:36:08AM +0100, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
> > +void __kprobes jprobe_return(void)
> > +{
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +
> > + /*
> > + * Jprobe handler return by entering break exception,
> > + * encoded same as kprobe, but with following conditions
> > + * -a magic number in x0 to identify from rest of other kprobes.
> > + * -restore stack addr to original saved pt_regs
> > + */
> > + asm volatile ("ldr x0, [%0]\n\t"
> > + "mov sp, x0\n\t"
> > + ".globl jprobe_return_break\n\t"
> > + "jprobe_return_break:\n\t"
> > + "brk %1\n\t"
> > + :
> > + : "r"(&kcb->jprobe_saved_regs.sp),
> > + "I"(BRK64_ESR_KPROBES)
> > + : "memory");
>
> A couple of remarks here:
> - the comment seems wrong, as you load the stack pointer in X0, nothing
> else, and seem to identify the jprobe by looking at the PC, not X0.
> - using explicit registers is really ugly. How about something like this
> instead:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c89811d..823cf92 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
> * -a magic number in x0 to identify from rest of other kprobes.
> * -restore stack addr to original saved pt_regs
> */
> - asm volatile ("ldr x0, [%0]\n\t"
> - "mov sp, x0\n\t"
> + asm volatile ("mov sp, %0\n\t"
> ".globl jprobe_return_break\n\t"
> "jprobe_return_break:\n\t"
> "brk %1\n\t"
> :
> - : "r"(&kcb->jprobe_saved_regs.sp),
> + : "r" (kcb->jprobe_saved_regs.sp),
> "I"(BRK64_ESR_KPROBES)
> : "memory");
> }
The comment indeed doesn't make any sense. Is x0 useful at all?
Otherwise, Marc's fixup looks better.
> though hijacking SP in the middle of a C function still feels pretty fragile.
It may not be that bad if this function is never supposed to return.
However, I no longer hit jprobe_return() in my tests, it fails earlier
when it hits the function entry breakpoint. One difference from the
default Kprobes tests is that tcp_rcv_established() runs in interrupt
context on the IRQ stack. Maybe setjmp_pre_handler() doesn't set things
up properly.
Also, is setjmp_pre_handler() guaranteed to run in a non-preemptible
context? It uses MIN_STACK_SIZE macro which does a
raw_smp_processor_id().
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 11:16 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 11:16 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 20, 2016 at 10:36:08AM +0100, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
> > +void __kprobes jprobe_return(void)
> > +{
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +
> > + /*
> > + * Jprobe handler return by entering break exception,
> > + * encoded same as kprobe, but with following conditions
> > + * -a magic number in x0 to identify from rest of other kprobes.
> > + * -restore stack addr to original saved pt_regs
> > + */
> > + asm volatile ("ldr x0, [%0]\n\t"
> > + "mov sp, x0\n\t"
> > + ".globl jprobe_return_break\n\t"
> > + "jprobe_return_break:\n\t"
> > + "brk %1\n\t"
> > + :
> > + : "r"(&kcb->jprobe_saved_regs.sp),
> > + "I"(BRK64_ESR_KPROBES)
> > + : "memory");
>
> A couple of remarks here:
> - the comment seems wrong, as you load the stack pointer in X0, nothing
> else, and seem to identify the jprobe by looking at the PC, not X0.
> - using explicit registers is really ugly. How about something like this
> instead:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c89811d..823cf92 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
> * -a magic number in x0 to identify from rest of other kprobes.
> * -restore stack addr to original saved pt_regs
> */
> - asm volatile ("ldr x0, [%0]\n\t"
> - "mov sp, x0\n\t"
> + asm volatile ("mov sp, %0\n\t"
> ".globl jprobe_return_break\n\t"
> "jprobe_return_break:\n\t"
> "brk %1\n\t"
> :
> - : "r"(&kcb->jprobe_saved_regs.sp),
> + : "r" (kcb->jprobe_saved_regs.sp),
> "I"(BRK64_ESR_KPROBES)
> : "memory");
> }
The comment indeed doesn't make any sense. Is x0 useful at all?
Otherwise, Marc's fixup looks better.
> though hijacking SP in the middle of a C function still feels pretty fragile.
It may not be that bad if this function is never supposed to return.
However, I no longer hit jprobe_return() in my tests, it fails earlier
when it hits the function entry breakpoint. One difference from the
default Kprobes tests is that tcp_rcv_established() runs in interrupt
context on the IRQ stack. Maybe setjmp_pre_handler() doesn't set things
up properly.
Also, is setjmp_pre_handler() guaranteed to run in a non-preemptible
context? It uses MIN_STACK_SIZE macro which does a
raw_smp_processor_id().
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-08 16:35 ` David Long
@ 2016-07-20 15:49 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 15:49 UTC (permalink / raw)
To: David Long
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote:
> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> + min((unsigned long)IRQ_STACK_SIZE, \
> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> + min((unsigned long)MAX_STACK_SIZE, \
> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
I presume you've never tested the on_irq_stack() path in this macro.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 15:49 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote:
> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> + min((unsigned long)IRQ_STACK_SIZE, \
> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> + min((unsigned long)MAX_STACK_SIZE, \
> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
I presume you've never tested the on_irq_stack() path in this macro.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-08 16:35 ` David Long
@ 2016-07-20 16:09 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:09 UTC (permalink / raw)
To: David Long, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 08/07/16 17:35, David Long wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
>
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.
>
> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
> kprobe, e.g.: during kprobes reenter so that probed instruction can be
> single stepped within the kprobe handler -exception- context.
> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
> any further re-entry is prevented by not calling handlers and the case
> counted as a missed kprobe).
>
> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
> like branching and symbolic literals access as the offset from the new PC
> (slot address) may not be ensured to fit in the immediate value of
> the opcode. Such instructions need simulation, so reject
> probing them.
>
> Instructions generating exceptions or cpu mode change are rejected
> for probing.
>
> Exclusive load/store instructions are rejected too. Additionally, the
> code is checked to see if it is inside an exclusive load/store sequence
> (code from Pratyush).
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> This also changes arch/arm64/include/asm/ptrace.h to use
> include/asm-generic/ptrace.h.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/debug-monitors.h | 5 +
> arch/arm64/include/asm/insn.h | 2 +
> arch/arm64/include/asm/kprobes.h | 60 ++++
> arch/arm64/include/asm/probes.h | 34 +++
> arch/arm64/include/asm/ptrace.h | 14 +-
> arch/arm64/kernel/Makefile | 2 +-
> arch/arm64/kernel/debug-monitors.c | 16 +-
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
> arch/arm64/kernel/probes/decode-insn.h | 34 +++
> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
> arch/arm64/kernel/vmlinux.lds.S | 1 +
> arch/arm64/mm/fault.c | 26 ++
> 14 files changed, 859 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm64/include/asm/kprobes.h
> create mode 100644 arch/arm64/include/asm/probes.h
> create mode 100644 arch/arm64/kernel/probes/Makefile
> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>
[...]
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> new file mode 100644
> index 0000000..79c9511
> --- /dev/null
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -0,0 +1,60 @@
> +/*
> + * arch/arm64/include/asm/kprobes.h
> + *
> + * Copyright (C) 2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _ARM_KPROBES_H
> +#define _ARM_KPROBES_H
> +
> +#include <linux/types.h>
> +#include <linux/ptrace.h>
> +#include <linux/percpu.h>
> +
> +#define __ARCH_WANT_KPROBES_INSN_SLOT
> +#define MAX_INSN_SIZE 1
> +#define MAX_STACK_SIZE 128
Where is that value coming from? Because even on my 6502, I have a 256
byte stack.
> +
> +#define flush_insn_slot(p) do { } while (0)
> +#define kretprobe_blacklist_size 0
> +
> +#include <asm/probes.h>
> +
> +struct prev_kprobe {
> + struct kprobe *kp;
> + unsigned int status;
> +};
> +
> +/* Single step context for kprobe */
> +struct kprobe_step_ctx {
> + unsigned long ss_pending;
> + unsigned long match_addr;
> +};
> +
> +/* per-cpu kprobe control block */
> +struct kprobe_ctlblk {
> + unsigned int kprobe_status;
> + unsigned long saved_irqflag;
> + struct prev_kprobe prev_kprobe;
> + struct kprobe_step_ctx ss_ctx;
> + struct pt_regs jprobe_saved_regs;
> + char jprobes_stack[MAX_STACK_SIZE];
Yeah, right. Let's keep this array in mind for a second.
> +};
> +
> +void arch_remove_kprobe(struct kprobe *);
> +int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
> +int kprobe_exceptions_notify(struct notifier_block *self,
> + unsigned long val, void *data);
> +int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
> +int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
> +
> +#endif /* _ARM_KPROBES_H */
> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
> new file mode 100644
> index 0000000..1e8a21a
[...]
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> new file mode 100644
> index 0000000..4496801
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -0,0 +1,525 @@
> +/*
> + * arch/arm64/kernel/probes/kprobes.c
> + *
> + * Kprobes support for ARM64
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + */
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/stop_machine.h>
> +#include <linux/stringify.h>
> +#include <asm/traps.h>
> +#include <asm/ptrace.h>
> +#include <asm/cacheflush.h>
> +#include <asm/debug-monitors.h>
> +#include <asm/system_misc.h>
> +#include <asm/insn.h>
> +#include <asm/uaccess.h>
> +#include <asm/irq.h>
> +
> +#include "decode-insn.h"
> +
> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> + min((unsigned long)IRQ_STACK_SIZE, \
> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> + min((unsigned long)MAX_STACK_SIZE, \
> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
This macro makes me want to throw things at people, because there is no
way it can be reasonable parsed. So I've converted it to:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..5ee9c54 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,11 +34,23 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+static unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long max_size;
+ unsigned long size;
+
+ if (on_irq_stack(addr, raw_smp_processor_id())) {
+ max_size = IRQ_STACK_SIZE;
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ } else {
+ max_size = MAX_STACK_SIZE;
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+ }
+
+ return min(size, max_size);
+}
+
+#define MIN_STACK_SIZE(addr) min_stack_size(addr)
void jprobe_return_break(void);
And then you can instrument it. If you add a simple printk to dump how
much you're going to copy, you get:
root@10:/# nc -l -p 8080
size = 1248
size = 1248
Bad mode in Synchronous Abort handler detected on CPU0, code 0x86000006 -- IABT (current EL)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc7-next-20160719-00068-g80315b6-dirty #6265
Hardware name: linux,dummy-virt (DT)
task: ffff000009020280 task.stack: ffff000009010000
PC is at 0x4000
LR is at enqueue_task_fair+0x8d8/0x1568
pc : [<0000000000004000>] lr : [<ffff000008101c78>] pstate: 200001c5
sp : ffff8000fffad7d0
Yes, 1248 bytes. How is that supposed to work?
So I've rewritten it like this:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..194a679 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,11 +34,20 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+static inline unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long size;
+ struct kprobe_ctlblk *ctl;
+
+ if (on_irq_stack(addr, raw_smp_processor_id()))
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ else
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+
+ return min(size, sizeof(ctl->jprobes_stack));
+}
+
+#define MIN_STACK_SIZE(addr) min_stack_size(addr)
void jprobe_return_break(void);
I'm not sure if these 128 bytes are the right size for this thing,
but at least it won't blindly take the kernel down.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 16:09 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:09 UTC (permalink / raw)
To: linux-arm-kernel
On 08/07/16 17:35, David Long wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
>
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.
>
> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
> kprobe, e.g.: during kprobes reenter so that probed instruction can be
> single stepped within the kprobe handler -exception- context.
> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
> any further re-entry is prevented by not calling handlers and the case
> counted as a missed kprobe).
>
> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
> like branching and symbolic literals access as the offset from the new PC
> (slot address) may not be ensured to fit in the immediate value of
> the opcode. Such instructions need simulation, so reject
> probing them.
>
> Instructions generating exceptions or cpu mode change are rejected
> for probing.
>
> Exclusive load/store instructions are rejected too. Additionally, the
> code is checked to see if it is inside an exclusive load/store sequence
> (code from Pratyush).
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> This also changes arch/arm64/include/asm/ptrace.h to use
> include/asm-generic/ptrace.h.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/debug-monitors.h | 5 +
> arch/arm64/include/asm/insn.h | 2 +
> arch/arm64/include/asm/kprobes.h | 60 ++++
> arch/arm64/include/asm/probes.h | 34 +++
> arch/arm64/include/asm/ptrace.h | 14 +-
> arch/arm64/kernel/Makefile | 2 +-
> arch/arm64/kernel/debug-monitors.c | 16 +-
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
> arch/arm64/kernel/probes/decode-insn.h | 34 +++
> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
> arch/arm64/kernel/vmlinux.lds.S | 1 +
> arch/arm64/mm/fault.c | 26 ++
> 14 files changed, 859 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm64/include/asm/kprobes.h
> create mode 100644 arch/arm64/include/asm/probes.h
> create mode 100644 arch/arm64/kernel/probes/Makefile
> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>
[...]
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> new file mode 100644
> index 0000000..79c9511
> --- /dev/null
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -0,0 +1,60 @@
> +/*
> + * arch/arm64/include/asm/kprobes.h
> + *
> + * Copyright (C) 2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _ARM_KPROBES_H
> +#define _ARM_KPROBES_H
> +
> +#include <linux/types.h>
> +#include <linux/ptrace.h>
> +#include <linux/percpu.h>
> +
> +#define __ARCH_WANT_KPROBES_INSN_SLOT
> +#define MAX_INSN_SIZE 1
> +#define MAX_STACK_SIZE 128
Where is that value coming from? Because even on my 6502, I have a 256
byte stack.
> +
> +#define flush_insn_slot(p) do { } while (0)
> +#define kretprobe_blacklist_size 0
> +
> +#include <asm/probes.h>
> +
> +struct prev_kprobe {
> + struct kprobe *kp;
> + unsigned int status;
> +};
> +
> +/* Single step context for kprobe */
> +struct kprobe_step_ctx {
> + unsigned long ss_pending;
> + unsigned long match_addr;
> +};
> +
> +/* per-cpu kprobe control block */
> +struct kprobe_ctlblk {
> + unsigned int kprobe_status;
> + unsigned long saved_irqflag;
> + struct prev_kprobe prev_kprobe;
> + struct kprobe_step_ctx ss_ctx;
> + struct pt_regs jprobe_saved_regs;
> + char jprobes_stack[MAX_STACK_SIZE];
Yeah, right. Let's keep this array in mind for a second.
> +};
> +
> +void arch_remove_kprobe(struct kprobe *);
> +int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
> +int kprobe_exceptions_notify(struct notifier_block *self,
> + unsigned long val, void *data);
> +int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
> +int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
> +
> +#endif /* _ARM_KPROBES_H */
> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
> new file mode 100644
> index 0000000..1e8a21a
[...]
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> new file mode 100644
> index 0000000..4496801
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -0,0 +1,525 @@
> +/*
> + * arch/arm64/kernel/probes/kprobes.c
> + *
> + * Kprobes support for ARM64
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + */
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/stop_machine.h>
> +#include <linux/stringify.h>
> +#include <asm/traps.h>
> +#include <asm/ptrace.h>
> +#include <asm/cacheflush.h>
> +#include <asm/debug-monitors.h>
> +#include <asm/system_misc.h>
> +#include <asm/insn.h>
> +#include <asm/uaccess.h>
> +#include <asm/irq.h>
> +
> +#include "decode-insn.h"
> +
> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> + min((unsigned long)IRQ_STACK_SIZE, \
> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> + min((unsigned long)MAX_STACK_SIZE, \
> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
This macro makes me want to throw things at people, because there is no
way it can be reasonable parsed. So I've converted it to:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..5ee9c54 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,11 +34,23 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+static unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long max_size;
+ unsigned long size;
+
+ if (on_irq_stack(addr, raw_smp_processor_id())) {
+ max_size = IRQ_STACK_SIZE;
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ } else {
+ max_size = MAX_STACK_SIZE;
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+ }
+
+ return min(size, max_size);
+}
+
+#define MIN_STACK_SIZE(addr) min_stack_size(addr)
void jprobe_return_break(void);
And then you can instrument it. If you add a simple printk to dump how
much you're going to copy, you get:
root at 10:/# nc -l -p 8080
size = 1248
size = 1248
Bad mode in Synchronous Abort handler detected on CPU0, code 0x86000006 -- IABT (current EL)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc7-next-20160719-00068-g80315b6-dirty #6265
Hardware name: linux,dummy-virt (DT)
task: ffff000009020280 task.stack: ffff000009010000
PC is at 0x4000
LR is at enqueue_task_fair+0x8d8/0x1568
pc : [<0000000000004000>] lr : [<ffff000008101c78>] pstate: 200001c5
sp : ffff8000fffad7d0
Yes, 1248 bytes. How is that supposed to work?
So I've rewritten it like this:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..194a679 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,11 +34,20 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
+static inline unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long size;
+ struct kprobe_ctlblk *ctl;
+
+ if (on_irq_stack(addr, raw_smp_processor_id()))
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ else
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+
+ return min(size, sizeof(ctl->jprobes_stack));
+}
+
+#define MIN_STACK_SIZE(addr) min_stack_size(addr)
void jprobe_return_break(void);
I'm not sure if these 128 bytes are the right size for this thing,
but at least it won't blindly take the kernel down.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 16:09 ` Marc Zyngier
@ 2016-07-20 16:28 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 16:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: David Long, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
> +static inline unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long size;
> + struct kprobe_ctlblk *ctl;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id()))
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + else
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> +
> + return min(size, sizeof(ctl->jprobes_stack));
> +}
We could drop the local ctl pointer:
return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
If you add a log, I'll push the patch on top of the kprobes branch.
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 16:28 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 16:28 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
> +static inline unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long size;
> + struct kprobe_ctlblk *ctl;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id()))
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + else
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> +
> + return min(size, sizeof(ctl->jprobes_stack));
> +}
We could drop the local ctl pointer:
return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
If you add a log, I'll push the patch on top of the kprobes branch.
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 16:28 ` Catalin Marinas
@ 2016-07-20 16:31 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:31 UTC (permalink / raw)
To: Catalin Marinas
Cc: David Long, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 20/07/16 17:28, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
>> +static inline unsigned long min_stack_size(unsigned long addr)
>> +{
>> + unsigned long size;
>> + struct kprobe_ctlblk *ctl;
>> +
>> + if (on_irq_stack(addr, raw_smp_processor_id()))
>> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> + else
>> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
>> +
>> + return min(size, sizeof(ctl->jprobes_stack));
>> +}
>
> We could drop the local ctl pointer:
>
> return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
>
> If you add a log, I'll push the patch on top of the kprobes branch.
Sure, I'll write that now.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 16:31 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:31 UTC (permalink / raw)
To: linux-arm-kernel
On 20/07/16 17:28, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
>> +static inline unsigned long min_stack_size(unsigned long addr)
>> +{
>> + unsigned long size;
>> + struct kprobe_ctlblk *ctl;
>> +
>> + if (on_irq_stack(addr, raw_smp_processor_id()))
>> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> + else
>> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
>> +
>> + return min(size, sizeof(ctl->jprobes_stack));
>> +}
>
> We could drop the local ctl pointer:
>
> return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
>
> If you add a log, I'll push the patch on top of the kprobes branch.
Sure, I'll write that now.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 16:28 ` Catalin Marinas
@ 2016-07-20 16:46 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: David Long, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 20/07/16 17:28, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
>> +static inline unsigned long min_stack_size(unsigned long addr)
>> +{
>> + unsigned long size;
>> + struct kprobe_ctlblk *ctl;
>> +
>> + if (on_irq_stack(addr, raw_smp_processor_id()))
>> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> + else
>> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
>> +
>> + return min(size, sizeof(ctl->jprobes_stack));
>> +}
>
> We could drop the local ctl pointer:
>
> return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
>
> If you add a log, I'll push the patch on top of the kprobes branch.
Here you go:
----8<----
>From 0d120f95b3348e1946d8a789c7147f316c27ea6b Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Wed, 20 Jul 2016 17:36:42 +0100
Subject: [PATCH] arm64: kprobes: Fix overflow when saving stack
The MIN_STACK_SIZE macro tries evaluate how much stack space needs
to be saved in the jprobes_stack array, sized at 128 bytes.
When using the IRQ stack, said macro can happily return up to
IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
This patch fixes things by getting rid of the crazy macro and
limiting the copy to be at most the size of the jprobes_stack
array, no matter which stack we're on.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/probes/kprobes.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..87a24f6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,12 +34,6 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
-
void jprobe_return_break(void);
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
@@ -48,6 +42,18 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+static inline unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long size;
+
+ if (on_irq_stack(addr, raw_smp_processor_id()))
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ else
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+
+ return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
+}
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -495,7 +501,7 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
* the argument area.
*/
memcpy(kcb->jprobes_stack, (void *)stack_ptr,
- MIN_STACK_SIZE(stack_ptr));
+ min_stack_size(stack_ptr));
instruction_pointer_set(regs, (unsigned long) jp->entry);
preempt_disable();
@@ -547,7 +553,7 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
unpause_graph_tracing();
*regs = kcb->jprobe_saved_regs;
memcpy((void *)stack_addr, kcb->jprobes_stack,
- MIN_STACK_SIZE(stack_addr));
+ min_stack_size(stack_addr));
preempt_enable_no_resched();
return 1;
}
--
2.1.4
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 16:46 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-20 16:46 UTC (permalink / raw)
To: linux-arm-kernel
On 20/07/16 17:28, Catalin Marinas wrote:
> On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
>> +static inline unsigned long min_stack_size(unsigned long addr)
>> +{
>> + unsigned long size;
>> + struct kprobe_ctlblk *ctl;
>> +
>> + if (on_irq_stack(addr, raw_smp_processor_id()))
>> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> + else
>> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
>> +
>> + return min(size, sizeof(ctl->jprobes_stack));
>> +}
>
> We could drop the local ctl pointer:
>
> return min(size, sizeof(((struct kprobe_ctlblk *)0)->jprobes_stack));
>
> If you add a log, I'll push the patch on top of the kprobes branch.
Here you go:
----8<----
>From 0d120f95b3348e1946d8a789c7147f316c27ea6b Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Wed, 20 Jul 2016 17:36:42 +0100
Subject: [PATCH] arm64: kprobes: Fix overflow when saving stack
The MIN_STACK_SIZE macro tries evaluate how much stack space needs
to be saved in the jprobes_stack array, sized at 128 bytes.
When using the IRQ stack, said macro can happily return up to
IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
This patch fixes things by getting rid of the crazy macro and
limiting the copy to be at most the size of the jprobes_stack
array, no matter which stack we're on.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/probes/kprobes.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 823cf92..87a24f6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,12 +34,6 @@
#include "decode-insn.h"
-#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
- min((unsigned long)IRQ_STACK_SIZE, \
- IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
- min((unsigned long)MAX_STACK_SIZE, \
- (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
-
void jprobe_return_break(void);
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
@@ -48,6 +42,18 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+static inline unsigned long min_stack_size(unsigned long addr)
+{
+ unsigned long size;
+
+ if (on_irq_stack(addr, raw_smp_processor_id()))
+ size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
+ else
+ size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
+
+ return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
+}
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -495,7 +501,7 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
* the argument area.
*/
memcpy(kcb->jprobes_stack, (void *)stack_ptr,
- MIN_STACK_SIZE(stack_ptr));
+ min_stack_size(stack_ptr));
instruction_pointer_set(regs, (unsigned long) jp->entry);
preempt_disable();
@@ -547,7 +553,7 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
unpause_graph_tracing();
*regs = kcb->jprobe_saved_regs;
memcpy((void *)stack_addr, kcb->jprobes_stack,
- MIN_STACK_SIZE(stack_addr));
+ min_stack_size(stack_addr));
preempt_enable_no_resched();
return 1;
}
--
2.1.4
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 16:46 ` Marc Zyngier
@ 2016-07-20 17:04 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 17:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, David Long, Huang Shijie,
Dave P Martin, Jisheng Zhang, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Wed, Jul 20, 2016 at 05:46:58PM +0100, Marc Zyngier wrote:
> From 0d120f95b3348e1946d8a789c7147f316c27ea6b Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <marc.zyngier@arm.com>
> Date: Wed, 20 Jul 2016 17:36:42 +0100
> Subject: [PATCH] arm64: kprobes: Fix overflow when saving stack
>
> The MIN_STACK_SIZE macro tries evaluate how much stack space needs
> to be saved in the jprobes_stack array, sized at 128 bytes.
>
> When using the IRQ stack, said macro can happily return up to
> IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
>
> This patch fixes things by getting rid of the crazy macro and
> limiting the copy to be at most the size of the jprobes_stack
> array, no matter which stack we're on.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Applied to the kprobes branch. Thanks.
(I can't yet tell whether kprobes will make into 4.8; I need to run some
more tests before deciding)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 17:04 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-20 17:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 20, 2016 at 05:46:58PM +0100, Marc Zyngier wrote:
> From 0d120f95b3348e1946d8a789c7147f316c27ea6b Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <marc.zyngier@arm.com>
> Date: Wed, 20 Jul 2016 17:36:42 +0100
> Subject: [PATCH] arm64: kprobes: Fix overflow when saving stack
>
> The MIN_STACK_SIZE macro tries evaluate how much stack space needs
> to be saved in the jprobes_stack array, sized at 128 bytes.
>
> When using the IRQ stack, said macro can happily return up to
> IRQ_STACK_SIZE, which is 16kB. Mayhem follows.
>
> This patch fixes things by getting rid of the crazy macro and
> limiting the copy to be at most the size of the jprobes_stack
> array, no matter which stack we're on.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Applied to the kprobes branch. Thanks.
(I can't yet tell whether kprobes will make into 4.8; I need to run some
more tests before deciding)
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
2016-07-19 13:46 ` Catalin Marinas
@ 2016-07-20 18:28 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-20 18:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/19/2016 09:46 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:52PM -0400, David Long wrote:
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
>> @@ -0,0 +1,85 @@
>> +/*
>> + * trampoline entry and return code for kretprobes.
>> + */
>> +
>> +#include <linux/linkage.h>
>> +#include <asm/asm-offsets.h>
>> +#include <asm/assembler.h>
>> +
>> + .text
>> +
>> +.macro save_all_base_regs
>> + stp x0, x1, [sp, #S_X0]
>> + stp x2, x3, [sp, #S_X2]
>> + stp x4, x5, [sp, #S_X4]
>> + stp x6, x7, [sp, #S_X6]
>> + stp x8, x9, [sp, #S_X8]
>> + stp x10, x11, [sp, #S_X10]
>> + stp x12, x13, [sp, #S_X12]
>> + stp x14, x15, [sp, #S_X14]
>> + stp x16, x17, [sp, #S_X16]
>> + stp x18, x19, [sp, #S_X18]
>> + stp x20, x21, [sp, #S_X20]
>> + stp x22, x23, [sp, #S_X22]
>> + stp x24, x25, [sp, #S_X24]
>> + stp x26, x27, [sp, #S_X26]
>> + stp x28, x29, [sp, #S_X28]
>> + add x0, sp, #S_FRAME_SIZE
>> + stp lr, x0, [sp, #S_LR]
>> +/*
>> + * Construct a useful saved PSTATE
>> + */
>> + mrs x0, nzcv
>> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
>> + mrs x1, daif
>> + and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
>
> I don't think you need the masking here, the mrs should return the
> corresponding 4 bits.
>
OK. I see you've done that.
>> + orr x0, x0, x1
>> + mrs x1, CurrentEL
>> + and x1, x1, #(3 << 2)
>> + orr x0, x1, x0
>> + mrs x1, SPSel
>> + and x1, x1, #1
>
> Same here.
OK. ^
>
>> + orr x0, x1, x0
>> + str x0, [sp, #S_PSTATE]
>> +.endm
>
> How is this pstate used, other than the restoring of the condition flag
> in the restore_all_base_regs macro? Does a kretprobes handler need
> access to them?
>
A kretprobes handler should probably be able to examine a reasonable
pstate value, particularly in terms of DAIF. As I recall not having a
valid DAIF was an issue at one time.
> Anyway, it's worth doing an stp xzr, x0, [sp, S_PC] so that we
> initialise the pc in pt_regs.
>
OK. Looks like you've done this.
>> +
>> +.macro restore_all_base_regs
>> + ldr x0, [sp, #S_PSTATE]
>> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
>> + msr nzcv, x0
>> + ldp x0, x1, [sp, #S_X0]
>> + ldp x2, x3, [sp, #S_X2]
>> + ldp x4, x5, [sp, #S_X4]
>> + ldp x6, x7, [sp, #S_X6]
>> + ldp x8, x9, [sp, #S_X8]
>> + ldp x10, x11, [sp, #S_X10]
>> + ldp x12, x13, [sp, #S_X12]
>> + ldp x14, x15, [sp, #S_X14]
>> + ldp x16, x17, [sp, #S_X16]
>> + ldp x18, x19, [sp, #S_X18]
>> + ldp x20, x21, [sp, #S_X20]
>> + ldp x22, x23, [sp, #S_X22]
>> + ldp x24, x25, [sp, #S_X24]
>> + ldp x26, x27, [sp, #S_X26]
>> + ldp x28, x29, [sp, #S_X28]
>> +.endm
>> +
>> +ENTRY(kretprobe_trampoline)
>> +
>> + sub sp, sp, #S_FRAME_SIZE
>> +
>> + save_all_base_regs
>> +
>> + mov x0, sp
>> + bl trampoline_probe_handler
>> + /* Replace trampoline address in lr with actual
>> + orig_ret_addr return address. */
>> + mov lr, x0
>> +
>> + restore_all_base_regs
>> +
>> + add sp, sp, #S_FRAME_SIZE
>> +
>> + ret
>> +
>> +ENDPROC(kretprobe_trampoline)
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 08/10] arm64: Add trampoline code for kretprobes
@ 2016-07-20 18:28 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-20 18:28 UTC (permalink / raw)
To: linux-arm-kernel
On 07/19/2016 09:46 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:52PM -0400, David Long wrote:
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
>> @@ -0,0 +1,85 @@
>> +/*
>> + * trampoline entry and return code for kretprobes.
>> + */
>> +
>> +#include <linux/linkage.h>
>> +#include <asm/asm-offsets.h>
>> +#include <asm/assembler.h>
>> +
>> + .text
>> +
>> +.macro save_all_base_regs
>> + stp x0, x1, [sp, #S_X0]
>> + stp x2, x3, [sp, #S_X2]
>> + stp x4, x5, [sp, #S_X4]
>> + stp x6, x7, [sp, #S_X6]
>> + stp x8, x9, [sp, #S_X8]
>> + stp x10, x11, [sp, #S_X10]
>> + stp x12, x13, [sp, #S_X12]
>> + stp x14, x15, [sp, #S_X14]
>> + stp x16, x17, [sp, #S_X16]
>> + stp x18, x19, [sp, #S_X18]
>> + stp x20, x21, [sp, #S_X20]
>> + stp x22, x23, [sp, #S_X22]
>> + stp x24, x25, [sp, #S_X24]
>> + stp x26, x27, [sp, #S_X26]
>> + stp x28, x29, [sp, #S_X28]
>> + add x0, sp, #S_FRAME_SIZE
>> + stp lr, x0, [sp, #S_LR]
>> +/*
>> + * Construct a useful saved PSTATE
>> + */
>> + mrs x0, nzcv
>> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
>> + mrs x1, daif
>> + and x1, x1, #(PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
>
> I don't think you need the masking here, the mrs should return the
> corresponding 4 bits.
>
OK. I see you've done that.
>> + orr x0, x0, x1
>> + mrs x1, CurrentEL
>> + and x1, x1, #(3 << 2)
>> + orr x0, x1, x0
>> + mrs x1, SPSel
>> + and x1, x1, #1
>
> Same here.
OK. ^
>
>> + orr x0, x1, x0
>> + str x0, [sp, #S_PSTATE]
>> +.endm
>
> How is this pstate used, other than the restoring of the condition flag
> in the restore_all_base_regs macro? Does a kretprobes handler need
> access to them?
>
A kretprobes handler should probably be able to examine a reasonable
pstate value, particularly in terms of DAIF. As I recall not having a
valid DAIF was an issue at one time.
> Anyway, it's worth doing an stp xzr, x0, [sp, S_PC] so that we
> initialise the pc in pt_regs.
>
OK. Looks like you've done this.
>> +
>> +.macro restore_all_base_regs
>> + ldr x0, [sp, #S_PSTATE]
>> + and x0, x0, #(PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT)
>> + msr nzcv, x0
>> + ldp x0, x1, [sp, #S_X0]
>> + ldp x2, x3, [sp, #S_X2]
>> + ldp x4, x5, [sp, #S_X4]
>> + ldp x6, x7, [sp, #S_X6]
>> + ldp x8, x9, [sp, #S_X8]
>> + ldp x10, x11, [sp, #S_X10]
>> + ldp x12, x13, [sp, #S_X12]
>> + ldp x14, x15, [sp, #S_X14]
>> + ldp x16, x17, [sp, #S_X16]
>> + ldp x18, x19, [sp, #S_X18]
>> + ldp x20, x21, [sp, #S_X20]
>> + ldp x22, x23, [sp, #S_X22]
>> + ldp x24, x25, [sp, #S_X24]
>> + ldp x26, x27, [sp, #S_X26]
>> + ldp x28, x29, [sp, #S_X28]
>> +.endm
>> +
>> +ENTRY(kretprobe_trampoline)
>> +
>> + sub sp, sp, #S_FRAME_SIZE
>> +
>> + save_all_base_regs
>> +
>> + mov x0, sp
>> + bl trampoline_probe_handler
>> + /* Replace trampoline address in lr with actual
>> + orig_ret_addr return address. */
>> + mov lr, x0
>> +
>> + restore_all_base_regs
>> +
>> + add sp, sp, #S_FRAME_SIZE
>> +
>> + ret
>> +
>> +ENDPROC(kretprobe_trampoline)
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 9:36 ` Marc Zyngier
@ 2016-07-20 19:08 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-20 19:08 UTC (permalink / raw)
To: Marc Zyngier, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 07/20/2016 05:36 AM, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>
>> Add support for basic kernel probes(kprobes) and jump probes
>> (jprobes) for ARM64.
>>
>> Kprobes utilizes software breakpoint and single step debug
>> exceptions supported on ARM v8.
>>
>> A software breakpoint is placed at the probe address to trap the
>> kernel execution into the kprobe handler.
>>
>> ARM v8 supports enabling single stepping before the break exception
>> return (ERET), with next PC in exception return address (ELR_EL1). The
>> kprobe handler prepares an executable memory slot for out-of-line
>> execution with a copy of the original instruction being probed, and
>> enables single stepping. The PC is set to the out-of-line slot address
>> before the ERET. With this scheme, the instruction is executed with the
>> exact same register context except for the PC (and DAIF) registers.
>>
>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>> single stepped within the kprobe handler -exception- context.
>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>> any further re-entry is prevented by not calling handlers and the case
>> counted as a missed kprobe).
>>
>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>> like branching and symbolic literals access as the offset from the new PC
>> (slot address) may not be ensured to fit in the immediate value of
>> the opcode. Such instructions need simulation, so reject
>> probing them.
>>
>> Instructions generating exceptions or cpu mode change are rejected
>> for probing.
>>
>> Exclusive load/store instructions are rejected too. Additionally, the
>> code is checked to see if it is inside an exclusive load/store sequence
>> (code from Pratyush).
>>
>> System instructions are mostly enabled for stepping, except MSR/MRS
>> accesses to "DAIF" flags in PSTATE, which are not safe for
>> probing.
>>
>> This also changes arch/arm64/include/asm/ptrace.h to use
>> include/asm-generic/ptrace.h.
>>
>> Thanks to Steve Capper and Pratyush Anand for several suggested
>> Changes.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>> ---
>
> [...]
>
>> +void __kprobes jprobe_return(void)
>> +{
>> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> +
>> + /*
>> + * Jprobe handler return by entering break exception,
>> + * encoded same as kprobe, but with following conditions
>> + * -a magic number in x0 to identify from rest of other kprobes.
>> + * -restore stack addr to original saved pt_regs
>> + */
>> + asm volatile ("ldr x0, [%0]\n\t"
>> + "mov sp, x0\n\t"
>> + ".globl jprobe_return_break\n\t"
>> + "jprobe_return_break:\n\t"
>> + "brk %1\n\t"
>> + :
>> + : "r"(&kcb->jprobe_saved_regs.sp),
>> + "I"(BRK64_ESR_KPROBES)
>> + : "memory");
>
> A couple of remarks here:
> - the comment seems wrong, as you load the stack pointer in X0, nothing
> else, and seem to identify the jprobe by looking at the PC, not X0.
Yes, this describes how it originally worked but I changed it based on
earlier feedback. Apparently this comment did not get updated.
> - using explicit registers is really ugly. How about something like this
> instead:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c89811d..823cf92 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
> * -a magic number in x0 to identify from rest of other kprobes.
> * -restore stack addr to original saved pt_regs
> */
> - asm volatile ("ldr x0, [%0]\n\t"
> - "mov sp, x0\n\t"
> + asm volatile ("mov sp, %0\n\t"
> ".globl jprobe_return_break\n\t"
> "jprobe_return_break:\n\t"
> "brk %1\n\t"
> :
> - : "r"(&kcb->jprobe_saved_regs.sp),
> + : "r" (kcb->jprobe_saved_regs.sp),
> "I"(BRK64_ESR_KPROBES)
> : "memory");
> }
>
OK
> though hijacking SP in the middle of a C function still feels pretty fragile.
>
> Thanks,
>
> M.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-20 19:08 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-20 19:08 UTC (permalink / raw)
To: linux-arm-kernel
On 07/20/2016 05:36 AM, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>
>> Add support for basic kernel probes(kprobes) and jump probes
>> (jprobes) for ARM64.
>>
>> Kprobes utilizes software breakpoint and single step debug
>> exceptions supported on ARM v8.
>>
>> A software breakpoint is placed at the probe address to trap the
>> kernel execution into the kprobe handler.
>>
>> ARM v8 supports enabling single stepping before the break exception
>> return (ERET), with next PC in exception return address (ELR_EL1). The
>> kprobe handler prepares an executable memory slot for out-of-line
>> execution with a copy of the original instruction being probed, and
>> enables single stepping. The PC is set to the out-of-line slot address
>> before the ERET. With this scheme, the instruction is executed with the
>> exact same register context except for the PC (and DAIF) registers.
>>
>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>> single stepped within the kprobe handler -exception- context.
>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>> any further re-entry is prevented by not calling handlers and the case
>> counted as a missed kprobe).
>>
>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>> like branching and symbolic literals access as the offset from the new PC
>> (slot address) may not be ensured to fit in the immediate value of
>> the opcode. Such instructions need simulation, so reject
>> probing them.
>>
>> Instructions generating exceptions or cpu mode change are rejected
>> for probing.
>>
>> Exclusive load/store instructions are rejected too. Additionally, the
>> code is checked to see if it is inside an exclusive load/store sequence
>> (code from Pratyush).
>>
>> System instructions are mostly enabled for stepping, except MSR/MRS
>> accesses to "DAIF" flags in PSTATE, which are not safe for
>> probing.
>>
>> This also changes arch/arm64/include/asm/ptrace.h to use
>> include/asm-generic/ptrace.h.
>>
>> Thanks to Steve Capper and Pratyush Anand for several suggested
>> Changes.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>> ---
>
> [...]
>
>> +void __kprobes jprobe_return(void)
>> +{
>> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> +
>> + /*
>> + * Jprobe handler return by entering break exception,
>> + * encoded same as kprobe, but with following conditions
>> + * -a magic number in x0 to identify from rest of other kprobes.
>> + * -restore stack addr to original saved pt_regs
>> + */
>> + asm volatile ("ldr x0, [%0]\n\t"
>> + "mov sp, x0\n\t"
>> + ".globl jprobe_return_break\n\t"
>> + "jprobe_return_break:\n\t"
>> + "brk %1\n\t"
>> + :
>> + : "r"(&kcb->jprobe_saved_regs.sp),
>> + "I"(BRK64_ESR_KPROBES)
>> + : "memory");
>
> A couple of remarks here:
> - the comment seems wrong, as you load the stack pointer in X0, nothing
> else, and seem to identify the jprobe by looking at the PC, not X0.
Yes, this describes how it originally worked but I changed it based on
earlier feedback. Apparently this comment did not get updated.
> - using explicit registers is really ugly. How about something like this
> instead:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c89811d..823cf92 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
> * -a magic number in x0 to identify from rest of other kprobes.
> * -restore stack addr to original saved pt_regs
> */
> - asm volatile ("ldr x0, [%0]\n\t"
> - "mov sp, x0\n\t"
> + asm volatile ("mov sp, %0\n\t"
> ".globl jprobe_return_break\n\t"
> "jprobe_return_break:\n\t"
> "brk %1\n\t"
> :
> - : "r"(&kcb->jprobe_saved_regs.sp),
> + : "r" (kcb->jprobe_saved_regs.sp),
> "I"(BRK64_ESR_KPROBES)
> : "memory");
> }
>
OK
> though hijacking SP in the middle of a C function still feels pretty fragile.
>
> Thanks,
>
> M.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 19:08 ` David Long
@ 2016-07-21 8:44 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-21 8:44 UTC (permalink / raw)
To: David Long, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 20/07/16 20:08, David Long wrote:
> On 07/20/2016 05:36 AM, Marc Zyngier wrote:
>> On 08/07/16 17:35, David Long wrote:
>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>
>>> Add support for basic kernel probes(kprobes) and jump probes
>>> (jprobes) for ARM64.
>>>
>>> Kprobes utilizes software breakpoint and single step debug
>>> exceptions supported on ARM v8.
>>>
>>> A software breakpoint is placed at the probe address to trap the
>>> kernel execution into the kprobe handler.
>>>
>>> ARM v8 supports enabling single stepping before the break exception
>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>> kprobe handler prepares an executable memory slot for out-of-line
>>> execution with a copy of the original instruction being probed, and
>>> enables single stepping. The PC is set to the out-of-line slot address
>>> before the ERET. With this scheme, the instruction is executed with the
>>> exact same register context except for the PC (and DAIF) registers.
>>>
>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>> single stepped within the kprobe handler -exception- context.
>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>> any further re-entry is prevented by not calling handlers and the case
>>> counted as a missed kprobe).
>>>
>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>> like branching and symbolic literals access as the offset from the new PC
>>> (slot address) may not be ensured to fit in the immediate value of
>>> the opcode. Such instructions need simulation, so reject
>>> probing them.
>>>
>>> Instructions generating exceptions or cpu mode change are rejected
>>> for probing.
>>>
>>> Exclusive load/store instructions are rejected too. Additionally, the
>>> code is checked to see if it is inside an exclusive load/store sequence
>>> (code from Pratyush).
>>>
>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>> probing.
>>>
>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>> include/asm-generic/ptrace.h.
>>>
>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>> Changes.
>>>
>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>> ---
>>
>> [...]
>>
>>> +void __kprobes jprobe_return(void)
>>> +{
>>> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>> +
>>> + /*
>>> + * Jprobe handler return by entering break exception,
>>> + * encoded same as kprobe, but with following conditions
>>> + * -a magic number in x0 to identify from rest of other kprobes.
>>> + * -restore stack addr to original saved pt_regs
>>> + */
>>> + asm volatile ("ldr x0, [%0]\n\t"
>>> + "mov sp, x0\n\t"
>>> + ".globl jprobe_return_break\n\t"
>>> + "jprobe_return_break:\n\t"
>>> + "brk %1\n\t"
>>> + :
>>> + : "r"(&kcb->jprobe_saved_regs.sp),
>>> + "I"(BRK64_ESR_KPROBES)
>>> + : "memory");
>>
>> A couple of remarks here:
>> - the comment seems wrong, as you load the stack pointer in X0, nothing
>> else, and seem to identify the jprobe by looking at the PC, not X0.
>
> Yes, this describes how it originally worked but I changed it based on
> earlier feedback. Apparently this comment did not get updated.
>
>> - using explicit registers is really ugly. How about something like this
>> instead:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
>> index c89811d..823cf92 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
>> * -a magic number in x0 to identify from rest of other kprobes.
>> * -restore stack addr to original saved pt_regs
>> */
>> - asm volatile ("ldr x0, [%0]\n\t"
>> - "mov sp, x0\n\t"
>> + asm volatile ("mov sp, %0\n\t"
>> ".globl jprobe_return_break\n\t"
>> "jprobe_return_break:\n\t"
>> "brk %1\n\t"
>> :
>> - : "r"(&kcb->jprobe_saved_regs.sp),
>> + : "r" (kcb->jprobe_saved_regs.sp),
>> "I"(BRK64_ESR_KPROBES)
>> : "memory");
>> }
>>
>
> OK
I'll take that as an ack. Catalin, would you mind applying something
like this:
----8<----
>From 3b5ef8eb99e75c56a38117d0f64884458db85527 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Wed, 20 Jul 2016 11:52:30 +0100
Subject: [PATCH] arm64: kprobes: Cleanup jprobe_return
jprobe_return seems to have aged badly. Comments refering to
non-existent behaviours, and a dangerous habit of messing
with registers without telling the compiler.
This patches applies the following remedies:
- Fix the comments to describe the actual behaviour
- Tidy up the asm sequence to directly assign the
stack pointer without clobbering extra registerse
- Mark the rest of the function as unreachable() so
that the compiler knows that there is no need for
an epilogue
- Stop making jprobe_return_break a global function
(you really don't want to call that guy, and it isn't
even a function).
Tested with tcp_probe.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/probes/kprobes.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 09f8ae9..973c15d 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,8 +34,6 @@
#include "decode-insn.h"
-void jprobe_return_break(void);
-
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -516,18 +514,17 @@ void __kprobes jprobe_return(void)
/*
* Jprobe handler return by entering break exception,
* encoded same as kprobe, but with following conditions
- * -a magic number in x0 to identify from rest of other kprobes.
+ * -a special PC to identify it from the other kprobes.
* -restore stack addr to original saved pt_regs
*/
- asm volatile ("ldr x0, [%0]\n\t"
- "mov sp, x0\n\t"
- ".globl jprobe_return_break\n\t"
- "jprobe_return_break:\n\t"
- "brk %1\n\t"
- :
- : "r"(&kcb->jprobe_saved_regs.sp),
- "I"(BRK64_ESR_KPROBES)
- : "memory");
+ asm volatile(" mov sp, %0 \n"
+ "jprobe_return_break: brk %1 \n"
+ :
+ : "r" (kcb->jprobe_saved_regs.sp),
+ "I" (BRK64_ESR_KPROBES)
+ : "memory");
+
+ unreachable();
}
int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
@@ -536,6 +533,7 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
long stack_addr = kcb->jprobe_saved_regs.sp;
long orig_sp = kernel_stack_pointer(regs);
struct jprobe *jp = container_of(p, struct jprobe, kp);
+ extern const char jprobe_return_break[];
if (instruction_pointer(regs) != (u64) jprobe_return_break)
return 0;
--
2.1.4
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 8:44 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-21 8:44 UTC (permalink / raw)
To: linux-arm-kernel
On 20/07/16 20:08, David Long wrote:
> On 07/20/2016 05:36 AM, Marc Zyngier wrote:
>> On 08/07/16 17:35, David Long wrote:
>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>
>>> Add support for basic kernel probes(kprobes) and jump probes
>>> (jprobes) for ARM64.
>>>
>>> Kprobes utilizes software breakpoint and single step debug
>>> exceptions supported on ARM v8.
>>>
>>> A software breakpoint is placed at the probe address to trap the
>>> kernel execution into the kprobe handler.
>>>
>>> ARM v8 supports enabling single stepping before the break exception
>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>> kprobe handler prepares an executable memory slot for out-of-line
>>> execution with a copy of the original instruction being probed, and
>>> enables single stepping. The PC is set to the out-of-line slot address
>>> before the ERET. With this scheme, the instruction is executed with the
>>> exact same register context except for the PC (and DAIF) registers.
>>>
>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>> single stepped within the kprobe handler -exception- context.
>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>> any further re-entry is prevented by not calling handlers and the case
>>> counted as a missed kprobe).
>>>
>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>> like branching and symbolic literals access as the offset from the new PC
>>> (slot address) may not be ensured to fit in the immediate value of
>>> the opcode. Such instructions need simulation, so reject
>>> probing them.
>>>
>>> Instructions generating exceptions or cpu mode change are rejected
>>> for probing.
>>>
>>> Exclusive load/store instructions are rejected too. Additionally, the
>>> code is checked to see if it is inside an exclusive load/store sequence
>>> (code from Pratyush).
>>>
>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>> probing.
>>>
>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>> include/asm-generic/ptrace.h.
>>>
>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>> Changes.
>>>
>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>> ---
>>
>> [...]
>>
>>> +void __kprobes jprobe_return(void)
>>> +{
>>> + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>> +
>>> + /*
>>> + * Jprobe handler return by entering break exception,
>>> + * encoded same as kprobe, but with following conditions
>>> + * -a magic number in x0 to identify from rest of other kprobes.
>>> + * -restore stack addr to original saved pt_regs
>>> + */
>>> + asm volatile ("ldr x0, [%0]\n\t"
>>> + "mov sp, x0\n\t"
>>> + ".globl jprobe_return_break\n\t"
>>> + "jprobe_return_break:\n\t"
>>> + "brk %1\n\t"
>>> + :
>>> + : "r"(&kcb->jprobe_saved_regs.sp),
>>> + "I"(BRK64_ESR_KPROBES)
>>> + : "memory");
>>
>> A couple of remarks here:
>> - the comment seems wrong, as you load the stack pointer in X0, nothing
>> else, and seem to identify the jprobe by looking at the PC, not X0.
>
> Yes, this describes how it originally worked but I changed it based on
> earlier feedback. Apparently this comment did not get updated.
>
>> - using explicit registers is really ugly. How about something like this
>> instead:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
>> index c89811d..823cf92 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
>> * -a magic number in x0 to identify from rest of other kprobes.
>> * -restore stack addr to original saved pt_regs
>> */
>> - asm volatile ("ldr x0, [%0]\n\t"
>> - "mov sp, x0\n\t"
>> + asm volatile ("mov sp, %0\n\t"
>> ".globl jprobe_return_break\n\t"
>> "jprobe_return_break:\n\t"
>> "brk %1\n\t"
>> :
>> - : "r"(&kcb->jprobe_saved_regs.sp),
>> + : "r" (kcb->jprobe_saved_regs.sp),
>> "I"(BRK64_ESR_KPROBES)
>> : "memory");
>> }
>>
>
> OK
I'll take that as an ack. Catalin, would you mind applying something
like this:
----8<----
>From 3b5ef8eb99e75c56a38117d0f64884458db85527 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Wed, 20 Jul 2016 11:52:30 +0100
Subject: [PATCH] arm64: kprobes: Cleanup jprobe_return
jprobe_return seems to have aged badly. Comments refering to
non-existent behaviours, and a dangerous habit of messing
with registers without telling the compiler.
This patches applies the following remedies:
- Fix the comments to describe the actual behaviour
- Tidy up the asm sequence to directly assign the
stack pointer without clobbering extra registerse
- Mark the rest of the function as unreachable() so
that the compiler knows that there is no need for
an epilogue
- Stop making jprobe_return_break a global function
(you really don't want to call that guy, and it isn't
even a function).
Tested with tcp_probe.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/probes/kprobes.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 09f8ae9..973c15d 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -34,8 +34,6 @@
#include "decode-insn.h"
-void jprobe_return_break(void);
-
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -516,18 +514,17 @@ void __kprobes jprobe_return(void)
/*
* Jprobe handler return by entering break exception,
* encoded same as kprobe, but with following conditions
- * -a magic number in x0 to identify from rest of other kprobes.
+ * -a special PC to identify it from the other kprobes.
* -restore stack addr to original saved pt_regs
*/
- asm volatile ("ldr x0, [%0]\n\t"
- "mov sp, x0\n\t"
- ".globl jprobe_return_break\n\t"
- "jprobe_return_break:\n\t"
- "brk %1\n\t"
- :
- : "r"(&kcb->jprobe_saved_regs.sp),
- "I"(BRK64_ESR_KPROBES)
- : "memory");
+ asm volatile(" mov sp, %0 \n"
+ "jprobe_return_break: brk %1 \n"
+ :
+ : "r" (kcb->jprobe_saved_regs.sp),
+ "I" (BRK64_ESR_KPROBES)
+ : "memory");
+
+ unreachable();
}
int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
@@ -536,6 +533,7 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
long stack_addr = kcb->jprobe_saved_regs.sp;
long orig_sp = kernel_stack_pointer(regs);
struct jprobe *jp = container_of(p, struct jprobe, kp);
+ extern const char jprobe_return_break[];
if (instruction_pointer(regs) != (u64) jprobe_return_break)
return 0;
--
2.1.4
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 15:49 ` Catalin Marinas
@ 2016-07-21 14:50 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 14:50 UTC (permalink / raw)
To: Catalin Marinas
Cc: Huang Shijie, James Morse, Marc Zyngier, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/20/2016 11:49 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote:
>> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
>> + min((unsigned long)IRQ_STACK_SIZE, \
>> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
>> + min((unsigned long)MAX_STACK_SIZE, \
>> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
>
> I presume you've never tested the on_irq_stack() path in this macro.
>
The combined patches were run through the test suite we've been using
all along. Apparently that either does not test jprobes on functions
using the interrupt stack or somehow just didn't happen to cause an
overwrite of something critical.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 14:50 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 14:50 UTC (permalink / raw)
To: linux-arm-kernel
On 07/20/2016 11:49 AM, Catalin Marinas wrote:
> On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote:
>> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
>> + min((unsigned long)IRQ_STACK_SIZE, \
>> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
>> + min((unsigned long)MAX_STACK_SIZE, \
>> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
>
> I presume you've never tested the on_irq_stack() path in this macro.
>
The combined patches were run through the test suite we've been using
all along. Apparently that either does not test jprobes on functions
using the interrupt stack or somehow just didn't happen to cause an
overwrite of something critical.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-20 16:09 ` Marc Zyngier
@ 2016-07-21 16:33 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 16:33 UTC (permalink / raw)
To: Marc Zyngier, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>
>> Add support for basic kernel probes(kprobes) and jump probes
>> (jprobes) for ARM64.
>>
>> Kprobes utilizes software breakpoint and single step debug
>> exceptions supported on ARM v8.
>>
>> A software breakpoint is placed at the probe address to trap the
>> kernel execution into the kprobe handler.
>>
>> ARM v8 supports enabling single stepping before the break exception
>> return (ERET), with next PC in exception return address (ELR_EL1). The
>> kprobe handler prepares an executable memory slot for out-of-line
>> execution with a copy of the original instruction being probed, and
>> enables single stepping. The PC is set to the out-of-line slot address
>> before the ERET. With this scheme, the instruction is executed with the
>> exact same register context except for the PC (and DAIF) registers.
>>
>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>> single stepped within the kprobe handler -exception- context.
>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>> any further re-entry is prevented by not calling handlers and the case
>> counted as a missed kprobe).
>>
>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>> like branching and symbolic literals access as the offset from the new PC
>> (slot address) may not be ensured to fit in the immediate value of
>> the opcode. Such instructions need simulation, so reject
>> probing them.
>>
>> Instructions generating exceptions or cpu mode change are rejected
>> for probing.
>>
>> Exclusive load/store instructions are rejected too. Additionally, the
>> code is checked to see if it is inside an exclusive load/store sequence
>> (code from Pratyush).
>>
>> System instructions are mostly enabled for stepping, except MSR/MRS
>> accesses to "DAIF" flags in PSTATE, which are not safe for
>> probing.
>>
>> This also changes arch/arm64/include/asm/ptrace.h to use
>> include/asm-generic/ptrace.h.
>>
>> Thanks to Steve Capper and Pratyush Anand for several suggested
>> Changes.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/debug-monitors.h | 5 +
>> arch/arm64/include/asm/insn.h | 2 +
>> arch/arm64/include/asm/kprobes.h | 60 ++++
>> arch/arm64/include/asm/probes.h | 34 +++
>> arch/arm64/include/asm/ptrace.h | 14 +-
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/debug-monitors.c | 16 +-
>> arch/arm64/kernel/probes/Makefile | 1 +
>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>> arch/arm64/mm/fault.c | 26 ++
>> 14 files changed, 859 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm64/include/asm/kprobes.h
>> create mode 100644 arch/arm64/include/asm/probes.h
>> create mode 100644 arch/arm64/kernel/probes/Makefile
>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>> new file mode 100644
>> index 0000000..79c9511
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -0,0 +1,60 @@
>> +/*
>> + * arch/arm64/include/asm/kprobes.h
>> + *
>> + * Copyright (C) 2013 Linaro Limited
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#ifndef _ARM_KPROBES_H
>> +#define _ARM_KPROBES_H
>> +
>> +#include <linux/types.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/percpu.h>
>> +
>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>> +#define MAX_INSN_SIZE 1
>> +#define MAX_STACK_SIZE 128
>
> Where is that value coming from? Because even on my 6502, I have a 256
> byte stack.
>
Although I don't claim to know the original author's thoughts I would
guess it is based on the seven other existing implementations for
kprobes on various architectures, all of which appear to use either 64
or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
whole stack.
>> +
>> +#define flush_insn_slot(p) do { } while (0)
>> +#define kretprobe_blacklist_size 0
>> +
>> +#include <asm/probes.h>
>> +
>> +struct prev_kprobe {
>> + struct kprobe *kp;
>> + unsigned int status;
>> +};
>> +
>> +/* Single step context for kprobe */
>> +struct kprobe_step_ctx {
>> + unsigned long ss_pending;
>> + unsigned long match_addr;
>> +};
>> +
>> +/* per-cpu kprobe control block */
>> +struct kprobe_ctlblk {
>> + unsigned int kprobe_status;
>> + unsigned long saved_irqflag;
>> + struct prev_kprobe prev_kprobe;
>> + struct kprobe_step_ctx ss_ctx;
>> + struct pt_regs jprobe_saved_regs;
>> + char jprobes_stack[MAX_STACK_SIZE];
>
> Yeah, right. Let's keep this array in mind for a second.
>
>> +};
>> +
>> +void arch_remove_kprobe(struct kprobe *);
>> +int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
>> +int kprobe_exceptions_notify(struct notifier_block *self,
>> + unsigned long val, void *data);
>> +int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
>> +int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
>> +
>> +#endif /* _ARM_KPROBES_H */
>> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
>> new file mode 100644
>> index 0000000..1e8a21a
>
> [...]
>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
>> new file mode 100644
>> index 0000000..4496801
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -0,0 +1,525 @@
>> +/*
>> + * arch/arm64/kernel/probes/kprobes.c
>> + *
>> + * Kprobes support for ARM64
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/stop_machine.h>
>> +#include <linux/stringify.h>
>> +#include <asm/traps.h>
>> +#include <asm/ptrace.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/debug-monitors.h>
>> +#include <asm/system_misc.h>
>> +#include <asm/insn.h>
>> +#include <asm/uaccess.h>
>> +#include <asm/irq.h>
>> +
>> +#include "decode-insn.h"
>> +
>> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
>> + min((unsigned long)IRQ_STACK_SIZE, \
>> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
>> + min((unsigned long)MAX_STACK_SIZE, \
>> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
>
> This macro makes me want to throw things at people, because there is no
> way it can be reasonable parsed. So I've converted it to:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 823cf92..5ee9c54 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -34,11 +34,23 @@
>
> #include "decode-insn.h"
>
> -#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> - min((unsigned long)IRQ_STACK_SIZE, \
> - IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> - min((unsigned long)MAX_STACK_SIZE, \
> - (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
> +static unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long max_size;
> + unsigned long size;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id())) {
> + max_size = IRQ_STACK_SIZE;
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + } else {
> + max_size = MAX_STACK_SIZE;
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> + }
> +
> + return min(size, max_size);
> +}
> +
> +#define MIN_STACK_SIZE(addr) min_stack_size(addr)
>
> void jprobe_return_break(void);
>
> And then you can instrument it. If you add a simple printk to dump how
> much you're going to copy, you get:
>
> root@10:/# nc -l -p 8080
> size = 1248
> size = 1248
> Bad mode in Synchronous Abort handler detected on CPU0, code 0x86000006 -- IABT (current EL)
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc7-next-20160719-00068-g80315b6-dirty #6265
> Hardware name: linux,dummy-virt (DT)
> task: ffff000009020280 task.stack: ffff000009010000
> PC is at 0x4000
> LR is at enqueue_task_fair+0x8d8/0x1568
> pc : [<0000000000004000>] lr : [<ffff000008101c78>] pstate: 200001c5
> sp : ffff8000fffad7d0
>
> Yes, 1248 bytes. How is that supposed to work?
>
> So I've rewritten it like this:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 823cf92..194a679 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -34,11 +34,20 @@
>
> #include "decode-insn.h"
>
> -#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> - min((unsigned long)IRQ_STACK_SIZE, \
> - IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> - min((unsigned long)MAX_STACK_SIZE, \
> - (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
> +static inline unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long size;
> + struct kprobe_ctlblk *ctl;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id()))
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + else
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> +
> + return min(size, sizeof(ctl->jprobes_stack));
> +}
> +
> +#define MIN_STACK_SIZE(addr) min_stack_size(addr)
>
> void jprobe_return_break(void);
>
>
> I'm not sure if these 128 bytes are the right size for this thing,
> but at least it won't blindly take the kernel down.
>
> Thanks,
>
> M.
>
Thanks for finding and fixing this bug.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 16:33 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 16:33 UTC (permalink / raw)
To: linux-arm-kernel
On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>
>> Add support for basic kernel probes(kprobes) and jump probes
>> (jprobes) for ARM64.
>>
>> Kprobes utilizes software breakpoint and single step debug
>> exceptions supported on ARM v8.
>>
>> A software breakpoint is placed at the probe address to trap the
>> kernel execution into the kprobe handler.
>>
>> ARM v8 supports enabling single stepping before the break exception
>> return (ERET), with next PC in exception return address (ELR_EL1). The
>> kprobe handler prepares an executable memory slot for out-of-line
>> execution with a copy of the original instruction being probed, and
>> enables single stepping. The PC is set to the out-of-line slot address
>> before the ERET. With this scheme, the instruction is executed with the
>> exact same register context except for the PC (and DAIF) registers.
>>
>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>> single stepped within the kprobe handler -exception- context.
>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>> any further re-entry is prevented by not calling handlers and the case
>> counted as a missed kprobe).
>>
>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>> like branching and symbolic literals access as the offset from the new PC
>> (slot address) may not be ensured to fit in the immediate value of
>> the opcode. Such instructions need simulation, so reject
>> probing them.
>>
>> Instructions generating exceptions or cpu mode change are rejected
>> for probing.
>>
>> Exclusive load/store instructions are rejected too. Additionally, the
>> code is checked to see if it is inside an exclusive load/store sequence
>> (code from Pratyush).
>>
>> System instructions are mostly enabled for stepping, except MSR/MRS
>> accesses to "DAIF" flags in PSTATE, which are not safe for
>> probing.
>>
>> This also changes arch/arm64/include/asm/ptrace.h to use
>> include/asm-generic/ptrace.h.
>>
>> Thanks to Steve Capper and Pratyush Anand for several suggested
>> Changes.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/debug-monitors.h | 5 +
>> arch/arm64/include/asm/insn.h | 2 +
>> arch/arm64/include/asm/kprobes.h | 60 ++++
>> arch/arm64/include/asm/probes.h | 34 +++
>> arch/arm64/include/asm/ptrace.h | 14 +-
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/debug-monitors.c | 16 +-
>> arch/arm64/kernel/probes/Makefile | 1 +
>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>> arch/arm64/mm/fault.c | 26 ++
>> 14 files changed, 859 insertions(+), 5 deletions(-)
>> create mode 100644 arch/arm64/include/asm/kprobes.h
>> create mode 100644 arch/arm64/include/asm/probes.h
>> create mode 100644 arch/arm64/kernel/probes/Makefile
>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>> new file mode 100644
>> index 0000000..79c9511
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -0,0 +1,60 @@
>> +/*
>> + * arch/arm64/include/asm/kprobes.h
>> + *
>> + * Copyright (C) 2013 Linaro Limited
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#ifndef _ARM_KPROBES_H
>> +#define _ARM_KPROBES_H
>> +
>> +#include <linux/types.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/percpu.h>
>> +
>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>> +#define MAX_INSN_SIZE 1
>> +#define MAX_STACK_SIZE 128
>
> Where is that value coming from? Because even on my 6502, I have a 256
> byte stack.
>
Although I don't claim to know the original author's thoughts I would
guess it is based on the seven other existing implementations for
kprobes on various architectures, all of which appear to use either 64
or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
whole stack.
>> +
>> +#define flush_insn_slot(p) do { } while (0)
>> +#define kretprobe_blacklist_size 0
>> +
>> +#include <asm/probes.h>
>> +
>> +struct prev_kprobe {
>> + struct kprobe *kp;
>> + unsigned int status;
>> +};
>> +
>> +/* Single step context for kprobe */
>> +struct kprobe_step_ctx {
>> + unsigned long ss_pending;
>> + unsigned long match_addr;
>> +};
>> +
>> +/* per-cpu kprobe control block */
>> +struct kprobe_ctlblk {
>> + unsigned int kprobe_status;
>> + unsigned long saved_irqflag;
>> + struct prev_kprobe prev_kprobe;
>> + struct kprobe_step_ctx ss_ctx;
>> + struct pt_regs jprobe_saved_regs;
>> + char jprobes_stack[MAX_STACK_SIZE];
>
> Yeah, right. Let's keep this array in mind for a second.
>
>> +};
>> +
>> +void arch_remove_kprobe(struct kprobe *);
>> +int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
>> +int kprobe_exceptions_notify(struct notifier_block *self,
>> + unsigned long val, void *data);
>> +int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
>> +int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
>> +
>> +#endif /* _ARM_KPROBES_H */
>> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
>> new file mode 100644
>> index 0000000..1e8a21a
>
> [...]
>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
>> new file mode 100644
>> index 0000000..4496801
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -0,0 +1,525 @@
>> +/*
>> + * arch/arm64/kernel/probes/kprobes.c
>> + *
>> + * Kprobes support for ARM64
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/stop_machine.h>
>> +#include <linux/stringify.h>
>> +#include <asm/traps.h>
>> +#include <asm/ptrace.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/debug-monitors.h>
>> +#include <asm/system_misc.h>
>> +#include <asm/insn.h>
>> +#include <asm/uaccess.h>
>> +#include <asm/irq.h>
>> +
>> +#include "decode-insn.h"
>> +
>> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
>> + min((unsigned long)IRQ_STACK_SIZE, \
>> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
>> + min((unsigned long)MAX_STACK_SIZE, \
>> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
>
> This macro makes me want to throw things at people, because there is no
> way it can be reasonable parsed. So I've converted it to:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 823cf92..5ee9c54 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -34,11 +34,23 @@
>
> #include "decode-insn.h"
>
> -#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> - min((unsigned long)IRQ_STACK_SIZE, \
> - IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> - min((unsigned long)MAX_STACK_SIZE, \
> - (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
> +static unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long max_size;
> + unsigned long size;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id())) {
> + max_size = IRQ_STACK_SIZE;
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + } else {
> + max_size = MAX_STACK_SIZE;
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> + }
> +
> + return min(size, max_size);
> +}
> +
> +#define MIN_STACK_SIZE(addr) min_stack_size(addr)
>
> void jprobe_return_break(void);
>
> And then you can instrument it. If you add a simple printk to dump how
> much you're going to copy, you get:
>
> root at 10:/# nc -l -p 8080
> size = 1248
> size = 1248
> Bad mode in Synchronous Abort handler detected on CPU0, code 0x86000006 -- IABT (current EL)
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc7-next-20160719-00068-g80315b6-dirty #6265
> Hardware name: linux,dummy-virt (DT)
> task: ffff000009020280 task.stack: ffff000009010000
> PC is at 0x4000
> LR is at enqueue_task_fair+0x8d8/0x1568
> pc : [<0000000000004000>] lr : [<ffff000008101c78>] pstate: 200001c5
> sp : ffff8000fffad7d0
>
> Yes, 1248 bytes. How is that supposed to work?
>
> So I've rewritten it like this:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 823cf92..194a679 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -34,11 +34,20 @@
>
> #include "decode-insn.h"
>
> -#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> - min((unsigned long)IRQ_STACK_SIZE, \
> - IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> - min((unsigned long)MAX_STACK_SIZE, \
> - (unsigned long)current_thread_info() + THREAD_START_SP - (addr)))
> +static inline unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long size;
> + struct kprobe_ctlblk *ctl;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id()))
> + size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> + else
> + size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> +
> + return min(size, sizeof(ctl->jprobes_stack));
> +}
> +
> +#define MIN_STACK_SIZE(addr) min_stack_size(addr)
>
> void jprobe_return_break(void);
>
>
> I'm not sure if these 128 bytes are the right size for this thing,
> but at least it won't blindly take the kernel down.
>
> Thanks,
>
> M.
>
Thanks for finding and fixing this bug.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-21 16:33 ` David Long
@ 2016-07-21 17:16 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-21 17:16 UTC (permalink / raw)
To: David Long
Cc: Marc Zyngier, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Thu, Jul 21, 2016 at 12:33:36PM -0400, David Long wrote:
> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >On 08/07/16 17:35, David Long wrote:
> >>diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> >>new file mode 100644
> >>index 0000000..79c9511
> >>--- /dev/null
> >>+++ b/arch/arm64/include/asm/kprobes.h
> >>@@ -0,0 +1,60 @@
> >>+/*
> >>+ * arch/arm64/include/asm/kprobes.h
> >>+ *
> >>+ * Copyright (C) 2013 Linaro Limited
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+ *
> >>+ * This program is distributed in the hope that it will be useful,
> >>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >>+ * General Public License for more details.
> >>+ */
> >>+
> >>+#ifndef _ARM_KPROBES_H
> >>+#define _ARM_KPROBES_H
> >>+
> >>+#include <linux/types.h>
> >>+#include <linux/ptrace.h>
> >>+#include <linux/percpu.h>
> >>+
> >>+#define __ARCH_WANT_KPROBES_INSN_SLOT
> >>+#define MAX_INSN_SIZE 1
> >>+#define MAX_STACK_SIZE 128
> >
> >Where is that value coming from? Because even on my 6502, I have a 256
> >byte stack.
>
> Although I don't claim to know the original author's thoughts I would guess
> it is based on the seven other existing implementations for kprobes on
> various architectures, all of which appear to use either 64 or 128 for
> MAX_STACK_SIZE. The code is not trying to duplicate the whole stack.
This seems to be some random choice in the hope that arguments passed on
the stack cannot exceed MAX_STACK_SIZE.
I'll put a patch together which checks the previous stack frame and
limit the copying. If the fp information or if the size to be copied
exceeds MAX_STACK_SIZE, just skip the probe hook (return 0 in
setjmp_pre_handler).
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 17:16 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 21, 2016 at 12:33:36PM -0400, David Long wrote:
> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >On 08/07/16 17:35, David Long wrote:
> >>diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> >>new file mode 100644
> >>index 0000000..79c9511
> >>--- /dev/null
> >>+++ b/arch/arm64/include/asm/kprobes.h
> >>@@ -0,0 +1,60 @@
> >>+/*
> >>+ * arch/arm64/include/asm/kprobes.h
> >>+ *
> >>+ * Copyright (C) 2013 Linaro Limited
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+ *
> >>+ * This program is distributed in the hope that it will be useful,
> >>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >>+ * General Public License for more details.
> >>+ */
> >>+
> >>+#ifndef _ARM_KPROBES_H
> >>+#define _ARM_KPROBES_H
> >>+
> >>+#include <linux/types.h>
> >>+#include <linux/ptrace.h>
> >>+#include <linux/percpu.h>
> >>+
> >>+#define __ARCH_WANT_KPROBES_INSN_SLOT
> >>+#define MAX_INSN_SIZE 1
> >>+#define MAX_STACK_SIZE 128
> >
> >Where is that value coming from? Because even on my 6502, I have a 256
> >byte stack.
>
> Although I don't claim to know the original author's thoughts I would guess
> it is based on the seven other existing implementations for kprobes on
> various architectures, all of which appear to use either 64 or 128 for
> MAX_STACK_SIZE. The code is not trying to duplicate the whole stack.
This seems to be some random choice in the hope that arguments passed on
the stack cannot exceed MAX_STACK_SIZE.
I'll put a patch together which checks the previous stack frame and
limit the copying. If the fp information or if the size to be copied
exceeds MAX_STACK_SIZE, just skip the probe hook (return 0 in
setjmp_pre_handler).
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-21 16:33 ` David Long
@ 2016-07-21 17:23 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-21 17:23 UTC (permalink / raw)
To: David Long, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 21/07/16 17:33, David Long wrote:
> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>> On 08/07/16 17:35, David Long wrote:
>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>
>>> Add support for basic kernel probes(kprobes) and jump probes
>>> (jprobes) for ARM64.
>>>
>>> Kprobes utilizes software breakpoint and single step debug
>>> exceptions supported on ARM v8.
>>>
>>> A software breakpoint is placed at the probe address to trap the
>>> kernel execution into the kprobe handler.
>>>
>>> ARM v8 supports enabling single stepping before the break exception
>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>> kprobe handler prepares an executable memory slot for out-of-line
>>> execution with a copy of the original instruction being probed, and
>>> enables single stepping. The PC is set to the out-of-line slot address
>>> before the ERET. With this scheme, the instruction is executed with the
>>> exact same register context except for the PC (and DAIF) registers.
>>>
>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>> single stepped within the kprobe handler -exception- context.
>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>> any further re-entry is prevented by not calling handlers and the case
>>> counted as a missed kprobe).
>>>
>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>> like branching and symbolic literals access as the offset from the new PC
>>> (slot address) may not be ensured to fit in the immediate value of
>>> the opcode. Such instructions need simulation, so reject
>>> probing them.
>>>
>>> Instructions generating exceptions or cpu mode change are rejected
>>> for probing.
>>>
>>> Exclusive load/store instructions are rejected too. Additionally, the
>>> code is checked to see if it is inside an exclusive load/store sequence
>>> (code from Pratyush).
>>>
>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>> probing.
>>>
>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>> include/asm-generic/ptrace.h.
>>>
>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>> Changes.
>>>
>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> arch/arm64/include/asm/debug-monitors.h | 5 +
>>> arch/arm64/include/asm/insn.h | 2 +
>>> arch/arm64/include/asm/kprobes.h | 60 ++++
>>> arch/arm64/include/asm/probes.h | 34 +++
>>> arch/arm64/include/asm/ptrace.h | 14 +-
>>> arch/arm64/kernel/Makefile | 2 +-
>>> arch/arm64/kernel/debug-monitors.c | 16 +-
>>> arch/arm64/kernel/probes/Makefile | 1 +
>>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>>> arch/arm64/mm/fault.c | 26 ++
>>> 14 files changed, 859 insertions(+), 5 deletions(-)
>>> create mode 100644 arch/arm64/include/asm/kprobes.h
>>> create mode 100644 arch/arm64/include/asm/probes.h
>>> create mode 100644 arch/arm64/kernel/probes/Makefile
>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>>
>>
>> [...]
>>
>>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>>> new file mode 100644
>>> index 0000000..79c9511
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/kprobes.h
>>> @@ -0,0 +1,60 @@
>>> +/*
>>> + * arch/arm64/include/asm/kprobes.h
>>> + *
>>> + * Copyright (C) 2013 Linaro Limited
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#ifndef _ARM_KPROBES_H
>>> +#define _ARM_KPROBES_H
>>> +
>>> +#include <linux/types.h>
>>> +#include <linux/ptrace.h>
>>> +#include <linux/percpu.h>
>>> +
>>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>>> +#define MAX_INSN_SIZE 1
>>> +#define MAX_STACK_SIZE 128
>>
>> Where is that value coming from? Because even on my 6502, I have a 256
>> byte stack.
>>
>
> Although I don't claim to know the original author's thoughts I would
> guess it is based on the seven other existing implementations for
> kprobes on various architectures, all of which appear to use either 64
> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> whole stack.
I get that (this was supposed to be a humorous comment, but I guess
after spending too much time tracking this thing, my own sense of humour
was becoming limited).
My main worry is that whatever value you pick, it is always going to be
wrong. This is used to preserve arguments that are passed on the stack,
as opposed to passed by registers). We have no idea of what is getting
passed there so saving nothing, 128 bytes or 2kB is about the same. It
is always wrong.
A much better solution would be to check the frame pointer, and copy the
delta between FP and SP, assuming it fits inside the allocated buffer.
If it doesn't, or if FP is invalid, we just skip the hook, because we
can't reliably execute it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 17:23 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2016-07-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
On 21/07/16 17:33, David Long wrote:
> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>> On 08/07/16 17:35, David Long wrote:
>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>
>>> Add support for basic kernel probes(kprobes) and jump probes
>>> (jprobes) for ARM64.
>>>
>>> Kprobes utilizes software breakpoint and single step debug
>>> exceptions supported on ARM v8.
>>>
>>> A software breakpoint is placed at the probe address to trap the
>>> kernel execution into the kprobe handler.
>>>
>>> ARM v8 supports enabling single stepping before the break exception
>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>> kprobe handler prepares an executable memory slot for out-of-line
>>> execution with a copy of the original instruction being probed, and
>>> enables single stepping. The PC is set to the out-of-line slot address
>>> before the ERET. With this scheme, the instruction is executed with the
>>> exact same register context except for the PC (and DAIF) registers.
>>>
>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>> single stepped within the kprobe handler -exception- context.
>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>> any further re-entry is prevented by not calling handlers and the case
>>> counted as a missed kprobe).
>>>
>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>> like branching and symbolic literals access as the offset from the new PC
>>> (slot address) may not be ensured to fit in the immediate value of
>>> the opcode. Such instructions need simulation, so reject
>>> probing them.
>>>
>>> Instructions generating exceptions or cpu mode change are rejected
>>> for probing.
>>>
>>> Exclusive load/store instructions are rejected too. Additionally, the
>>> code is checked to see if it is inside an exclusive load/store sequence
>>> (code from Pratyush).
>>>
>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>> probing.
>>>
>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>> include/asm-generic/ptrace.h.
>>>
>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>> Changes.
>>>
>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> arch/arm64/include/asm/debug-monitors.h | 5 +
>>> arch/arm64/include/asm/insn.h | 2 +
>>> arch/arm64/include/asm/kprobes.h | 60 ++++
>>> arch/arm64/include/asm/probes.h | 34 +++
>>> arch/arm64/include/asm/ptrace.h | 14 +-
>>> arch/arm64/kernel/Makefile | 2 +-
>>> arch/arm64/kernel/debug-monitors.c | 16 +-
>>> arch/arm64/kernel/probes/Makefile | 1 +
>>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>>> arch/arm64/mm/fault.c | 26 ++
>>> 14 files changed, 859 insertions(+), 5 deletions(-)
>>> create mode 100644 arch/arm64/include/asm/kprobes.h
>>> create mode 100644 arch/arm64/include/asm/probes.h
>>> create mode 100644 arch/arm64/kernel/probes/Makefile
>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>>
>>
>> [...]
>>
>>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>>> new file mode 100644
>>> index 0000000..79c9511
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/kprobes.h
>>> @@ -0,0 +1,60 @@
>>> +/*
>>> + * arch/arm64/include/asm/kprobes.h
>>> + *
>>> + * Copyright (C) 2013 Linaro Limited
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#ifndef _ARM_KPROBES_H
>>> +#define _ARM_KPROBES_H
>>> +
>>> +#include <linux/types.h>
>>> +#include <linux/ptrace.h>
>>> +#include <linux/percpu.h>
>>> +
>>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>>> +#define MAX_INSN_SIZE 1
>>> +#define MAX_STACK_SIZE 128
>>
>> Where is that value coming from? Because even on my 6502, I have a 256
>> byte stack.
>>
>
> Although I don't claim to know the original author's thoughts I would
> guess it is based on the seven other existing implementations for
> kprobes on various architectures, all of which appear to use either 64
> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> whole stack.
I get that (this was supposed to be a humorous comment, but I guess
after spending too much time tracking this thing, my own sense of humour
was becoming limited).
My main worry is that whatever value you pick, it is always going to be
wrong. This is used to preserve arguments that are passed on the stack,
as opposed to passed by registers). We have no idea of what is getting
passed there so saving nothing, 128 bytes or 2kB is about the same. It
is always wrong.
A much better solution would be to check the frame pointer, and copy the
delta between FP and SP, assuming it fits inside the allocated buffer.
If it doesn't, or if FP is invalid, we just skip the hook, because we
can't reliably execute it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-21 17:23 ` Marc Zyngier
@ 2016-07-21 18:33 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 18:33 UTC (permalink / raw)
To: Marc Zyngier, Catalin Marinas, Huang Shijie, James Morse,
Pratyush Anand, Sandeepa Prabhu, Will Deacon, William Cohen,
linux-arm-kernel, linux-kernel, Steve Capper, Masami Hiramatsu,
Li Bin
Cc: Adam Buchbinder, Alex Bennée, Andrew Morton,
Andrey Ryabinin, Ard Biesheuvel, Christoffer Dall,
Daniel Thompson, Dave P Martin, Jens Wiklander, Jisheng Zhang,
John Blackwood, Mark Rutland, Petr Mladek, Robin Murphy,
Suzuki K Poulose, Vladimir Murzin, Yang Shi, Zi Shen Lim,
yalin wang, Mark Brown
On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> On 21/07/16 17:33, David Long wrote:
>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>> On 08/07/16 17:35, David Long wrote:
>>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>>
>>>> Add support for basic kernel probes(kprobes) and jump probes
>>>> (jprobes) for ARM64.
>>>>
>>>> Kprobes utilizes software breakpoint and single step debug
>>>> exceptions supported on ARM v8.
>>>>
>>>> A software breakpoint is placed at the probe address to trap the
>>>> kernel execution into the kprobe handler.
>>>>
>>>> ARM v8 supports enabling single stepping before the break exception
>>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>>> kprobe handler prepares an executable memory slot for out-of-line
>>>> execution with a copy of the original instruction being probed, and
>>>> enables single stepping. The PC is set to the out-of-line slot address
>>>> before the ERET. With this scheme, the instruction is executed with the
>>>> exact same register context except for the PC (and DAIF) registers.
>>>>
>>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>>> single stepped within the kprobe handler -exception- context.
>>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>>> any further re-entry is prevented by not calling handlers and the case
>>>> counted as a missed kprobe).
>>>>
>>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>>> like branching and symbolic literals access as the offset from the new PC
>>>> (slot address) may not be ensured to fit in the immediate value of
>>>> the opcode. Such instructions need simulation, so reject
>>>> probing them.
>>>>
>>>> Instructions generating exceptions or cpu mode change are rejected
>>>> for probing.
>>>>
>>>> Exclusive load/store instructions are rejected too. Additionally, the
>>>> code is checked to see if it is inside an exclusive load/store sequence
>>>> (code from Pratyush).
>>>>
>>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>>> probing.
>>>>
>>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>>> include/asm-generic/ptrace.h.
>>>>
>>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>>> Changes.
>>>>
>>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>>> ---
>>>> arch/arm64/Kconfig | 1 +
>>>> arch/arm64/include/asm/debug-monitors.h | 5 +
>>>> arch/arm64/include/asm/insn.h | 2 +
>>>> arch/arm64/include/asm/kprobes.h | 60 ++++
>>>> arch/arm64/include/asm/probes.h | 34 +++
>>>> arch/arm64/include/asm/ptrace.h | 14 +-
>>>> arch/arm64/kernel/Makefile | 2 +-
>>>> arch/arm64/kernel/debug-monitors.c | 16 +-
>>>> arch/arm64/kernel/probes/Makefile | 1 +
>>>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>>>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>>>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>>>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>>>> arch/arm64/mm/fault.c | 26 ++
>>>> 14 files changed, 859 insertions(+), 5 deletions(-)
>>>> create mode 100644 arch/arm64/include/asm/kprobes.h
>>>> create mode 100644 arch/arm64/include/asm/probes.h
>>>> create mode 100644 arch/arm64/kernel/probes/Makefile
>>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>>>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>>>
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>>>> new file mode 100644
>>>> index 0000000..79c9511
>>>> --- /dev/null
>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>> @@ -0,0 +1,60 @@
>>>> +/*
>>>> + * arch/arm64/include/asm/kprobes.h
>>>> + *
>>>> + * Copyright (C) 2013 Linaro Limited
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>>> + * General Public License for more details.
>>>> + */
>>>> +
>>>> +#ifndef _ARM_KPROBES_H
>>>> +#define _ARM_KPROBES_H
>>>> +
>>>> +#include <linux/types.h>
>>>> +#include <linux/ptrace.h>
>>>> +#include <linux/percpu.h>
>>>> +
>>>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>>>> +#define MAX_INSN_SIZE 1
>>>> +#define MAX_STACK_SIZE 128
>>>
>>> Where is that value coming from? Because even on my 6502, I have a 256
>>> byte stack.
>>>
>>
>> Although I don't claim to know the original author's thoughts I would
>> guess it is based on the seven other existing implementations for
>> kprobes on various architectures, all of which appear to use either 64
>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>> whole stack.
>
> I get that (this was supposed to be a humorous comment, but I guess
> after spending too much time tracking this thing, my own sense of humour
> was becoming limited).
>
It was only meant to be factual.
> My main worry is that whatever value you pick, it is always going to be
> wrong. This is used to preserve arguments that are passed on the stack,
> as opposed to passed by registers). We have no idea of what is getting
> passed there so saving nothing, 128 bytes or 2kB is about the same. It
> is always wrong.
>
> A much better solution would be to check the frame pointer, and copy the
> delta between FP and SP, assuming it fits inside the allocated buffer.
> If it doesn't, or if FP is invalid, we just skip the hook, because we
> can't reliably execute it.
Well, this is the way it works literally everywhere else. It is a
documented limitation (Documentation/kprobes.txt). Said documentation
may need to be changed along with the suggested fix.
While it might be nice if there were less of a limitation it doesn't
feel wise to me to be making this change at this time. It feels like an
enhancement to consider amongst future improvements for all architectures.
>
> Thanks,
>
> M.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-21 18:33 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> On 21/07/16 17:33, David Long wrote:
>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>> On 08/07/16 17:35, David Long wrote:
>>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>>
>>>> Add support for basic kernel probes(kprobes) and jump probes
>>>> (jprobes) for ARM64.
>>>>
>>>> Kprobes utilizes software breakpoint and single step debug
>>>> exceptions supported on ARM v8.
>>>>
>>>> A software breakpoint is placed at the probe address to trap the
>>>> kernel execution into the kprobe handler.
>>>>
>>>> ARM v8 supports enabling single stepping before the break exception
>>>> return (ERET), with next PC in exception return address (ELR_EL1). The
>>>> kprobe handler prepares an executable memory slot for out-of-line
>>>> execution with a copy of the original instruction being probed, and
>>>> enables single stepping. The PC is set to the out-of-line slot address
>>>> before the ERET. With this scheme, the instruction is executed with the
>>>> exact same register context except for the PC (and DAIF) registers.
>>>>
>>>> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
>>>> kprobe, e.g.: during kprobes reenter so that probed instruction can be
>>>> single stepped within the kprobe handler -exception- context.
>>>> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
>>>> any further re-entry is prevented by not calling handlers and the case
>>>> counted as a missed kprobe).
>>>>
>>>> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
>>>> like branching and symbolic literals access as the offset from the new PC
>>>> (slot address) may not be ensured to fit in the immediate value of
>>>> the opcode. Such instructions need simulation, so reject
>>>> probing them.
>>>>
>>>> Instructions generating exceptions or cpu mode change are rejected
>>>> for probing.
>>>>
>>>> Exclusive load/store instructions are rejected too. Additionally, the
>>>> code is checked to see if it is inside an exclusive load/store sequence
>>>> (code from Pratyush).
>>>>
>>>> System instructions are mostly enabled for stepping, except MSR/MRS
>>>> accesses to "DAIF" flags in PSTATE, which are not safe for
>>>> probing.
>>>>
>>>> This also changes arch/arm64/include/asm/ptrace.h to use
>>>> include/asm-generic/ptrace.h.
>>>>
>>>> Thanks to Steve Capper and Pratyush Anand for several suggested
>>>> Changes.
>>>>
>>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>>>> ---
>>>> arch/arm64/Kconfig | 1 +
>>>> arch/arm64/include/asm/debug-monitors.h | 5 +
>>>> arch/arm64/include/asm/insn.h | 2 +
>>>> arch/arm64/include/asm/kprobes.h | 60 ++++
>>>> arch/arm64/include/asm/probes.h | 34 +++
>>>> arch/arm64/include/asm/ptrace.h | 14 +-
>>>> arch/arm64/kernel/Makefile | 2 +-
>>>> arch/arm64/kernel/debug-monitors.c | 16 +-
>>>> arch/arm64/kernel/probes/Makefile | 1 +
>>>> arch/arm64/kernel/probes/decode-insn.c | 143 +++++++++
>>>> arch/arm64/kernel/probes/decode-insn.h | 34 +++
>>>> arch/arm64/kernel/probes/kprobes.c | 525 ++++++++++++++++++++++++++++++++
>>>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>>>> arch/arm64/mm/fault.c | 26 ++
>>>> 14 files changed, 859 insertions(+), 5 deletions(-)
>>>> create mode 100644 arch/arm64/include/asm/kprobes.h
>>>> create mode 100644 arch/arm64/include/asm/probes.h
>>>> create mode 100644 arch/arm64/kernel/probes/Makefile
>>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.c
>>>> create mode 100644 arch/arm64/kernel/probes/decode-insn.h
>>>> create mode 100644 arch/arm64/kernel/probes/kprobes.c
>>>>
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>>>> new file mode 100644
>>>> index 0000000..79c9511
>>>> --- /dev/null
>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>> @@ -0,0 +1,60 @@
>>>> +/*
>>>> + * arch/arm64/include/asm/kprobes.h
>>>> + *
>>>> + * Copyright (C) 2013 Linaro Limited
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>>> + * General Public License for more details.
>>>> + */
>>>> +
>>>> +#ifndef _ARM_KPROBES_H
>>>> +#define _ARM_KPROBES_H
>>>> +
>>>> +#include <linux/types.h>
>>>> +#include <linux/ptrace.h>
>>>> +#include <linux/percpu.h>
>>>> +
>>>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>>>> +#define MAX_INSN_SIZE 1
>>>> +#define MAX_STACK_SIZE 128
>>>
>>> Where is that value coming from? Because even on my 6502, I have a 256
>>> byte stack.
>>>
>>
>> Although I don't claim to know the original author's thoughts I would
>> guess it is based on the seven other existing implementations for
>> kprobes on various architectures, all of which appear to use either 64
>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>> whole stack.
>
> I get that (this was supposed to be a humorous comment, but I guess
> after spending too much time tracking this thing, my own sense of humour
> was becoming limited).
>
It was only meant to be factual.
> My main worry is that whatever value you pick, it is always going to be
> wrong. This is used to preserve arguments that are passed on the stack,
> as opposed to passed by registers). We have no idea of what is getting
> passed there so saving nothing, 128 bytes or 2kB is about the same. It
> is always wrong.
>
> A much better solution would be to check the frame pointer, and copy the
> delta between FP and SP, assuming it fits inside the allocated buffer.
> If it doesn't, or if FP is invalid, we just skip the hook, because we
> can't reliably execute it.
Well, this is the way it works literally everywhere else. It is a
documented limitation (Documentation/kprobes.txt). Said documentation
may need to be changed along with the suggested fix.
While it might be nice if there were less of a limitation it doesn't
feel wise to me to be making this change at this time. It feels like an
enhancement to consider amongst future improvements for all architectures.
>
> Thanks,
>
> M.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-21 18:33 ` David Long
@ 2016-07-22 10:16 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-22 10:16 UTC (permalink / raw)
To: David Long
Cc: Marc Zyngier, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> >On 21/07/16 17:33, David Long wrote:
> >>On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >>>On 08/07/16 17:35, David Long wrote:
> >>>>+#define MAX_INSN_SIZE 1
> >>>>+#define MAX_STACK_SIZE 128
> >>>
> >>>Where is that value coming from? Because even on my 6502, I have a 256
> >>>byte stack.
> >>>
> >>
> >>Although I don't claim to know the original author's thoughts I would
> >>guess it is based on the seven other existing implementations for
> >>kprobes on various architectures, all of which appear to use either 64
> >>or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> >>whole stack.
[...]
> >My main worry is that whatever value you pick, it is always going to be
> >wrong. This is used to preserve arguments that are passed on the stack,
> >as opposed to passed by registers). We have no idea of what is getting
> >passed there so saving nothing, 128 bytes or 2kB is about the same. It
> >is always wrong.
> >
> >A much better solution would be to check the frame pointer, and copy the
> >delta between FP and SP, assuming it fits inside the allocated buffer.
> >If it doesn't, or if FP is invalid, we just skip the hook, because we
> >can't reliably execute it.
>
> Well, this is the way it works literally everywhere else. It is a documented
> limitation (Documentation/kprobes.txt). Said documentation may need to be
> changed along with the suggested fix.
The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
the arch code could always copy less but never more than MAX_STACK_SIZE.
What we are proposing is that we should try to guess how much to copy
based on the FP value (caller's frame) and, if larger than
MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
against the kprobes.txt document but at least it (a) may improve the
performance slightly by avoiding unnecessary copy and (b) it avoids
undefined behaviour if we ever encounter a jprobe with arguments passed
on the stack beyond MAX_STACK_SIZE.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-22 10:16 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-22 10:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> >On 21/07/16 17:33, David Long wrote:
> >>On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >>>On 08/07/16 17:35, David Long wrote:
> >>>>+#define MAX_INSN_SIZE 1
> >>>>+#define MAX_STACK_SIZE 128
> >>>
> >>>Where is that value coming from? Because even on my 6502, I have a 256
> >>>byte stack.
> >>>
> >>
> >>Although I don't claim to know the original author's thoughts I would
> >>guess it is based on the seven other existing implementations for
> >>kprobes on various architectures, all of which appear to use either 64
> >>or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> >>whole stack.
[...]
> >My main worry is that whatever value you pick, it is always going to be
> >wrong. This is used to preserve arguments that are passed on the stack,
> >as opposed to passed by registers). We have no idea of what is getting
> >passed there so saving nothing, 128 bytes or 2kB is about the same. It
> >is always wrong.
> >
> >A much better solution would be to check the frame pointer, and copy the
> >delta between FP and SP, assuming it fits inside the allocated buffer.
> >If it doesn't, or if FP is invalid, we just skip the hook, because we
> >can't reliably execute it.
>
> Well, this is the way it works literally everywhere else. It is a documented
> limitation (Documentation/kprobes.txt). Said documentation may need to be
> changed along with the suggested fix.
The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
the arch code could always copy less but never more than MAX_STACK_SIZE.
What we are proposing is that we should try to guess how much to copy
based on the FP value (caller's frame) and, if larger than
MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
against the kprobes.txt document but at least it (a) may improve the
performance slightly by avoiding unnecessary copy and (b) it avoids
undefined behaviour if we ever encounter a jprobe with arguments passed
on the stack beyond MAX_STACK_SIZE.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-22 10:16 ` Catalin Marinas
@ 2016-07-22 15:51 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-22 15:51 UTC (permalink / raw)
To: Catalin Marinas
Cc: Marc Zyngier, Huang Shijie, James Morse, Pratyush Anand,
Sandeepa Prabhu, Will Deacon, William Cohen, linux-arm-kernel,
linux-kernel, Steve Capper, Masami Hiramatsu, Li Bin,
Jisheng Zhang, Mark Rutland, Daniel Thompson, Vladimir Murzin,
Petr Mladek, Ard Biesheuvel, Jens Wiklander, Robin Murphy,
Mark Brown, Suzuki K Poulose, Dave P Martin, Andrey Ryabinin,
yalin wang, Yang Shi, Zi Shen Lim, John Blackwood, Andrew Morton,
Alex Bennée, Adam Buchbinder, Christoffer Dall
On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>> On 21/07/16 17:33, David Long wrote:
>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>> +#define MAX_INSN_SIZE 1
>>>>>> +#define MAX_STACK_SIZE 128
>>>>>
>>>>> Where is that value coming from? Because even on my 6502, I have a 256
>>>>> byte stack.
>>>>>
>>>>
>>>> Although I don't claim to know the original author's thoughts I would
>>>> guess it is based on the seven other existing implementations for
>>>> kprobes on various architectures, all of which appear to use either 64
>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>> whole stack.
> [...]
>>> My main worry is that whatever value you pick, it is always going to be
>>> wrong. This is used to preserve arguments that are passed on the stack,
>>> as opposed to passed by registers). We have no idea of what is getting
>>> passed there so saving nothing, 128 bytes or 2kB is about the same. It
>>> is always wrong.
>>>
>>> A much better solution would be to check the frame pointer, and copy the
>>> delta between FP and SP, assuming it fits inside the allocated buffer.
>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>> can't reliably execute it.
>>
>> Well, this is the way it works literally everywhere else. It is a documented
>> limitation (Documentation/kprobes.txt). Said documentation may need to be
>> changed along with the suggested fix.
>
> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> the arch code could always copy less but never more than MAX_STACK_SIZE.
> What we are proposing is that we should try to guess how much to copy
> based on the FP value (caller's frame) and, if larger than
> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> against the kprobes.txt document but at least it (a) may improve the
> performance slightly by avoiding unnecessary copy and (b) it avoids
> undefined behaviour if we ever encounter a jprobe with arguments passed
> on the stack beyond MAX_STACK_SIZE.
>
OK, it sounds like an improvement. I do worry a little about unexpected
side effects. I'm just asking if we can accept the existing code as now
complete enough (in that I believe it matches the other implementations)
and make this enhancement something for the next release cycle, allowing
the existing code to be exercised by a wider audience and providing
ample time to test the new modification? I'd hate to get stuck in a mode
where this patch gets repeatedly delayed for changes that go above and
beyond the original design.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-22 15:51 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-22 15:51 UTC (permalink / raw)
To: linux-arm-kernel
On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>> On 21/07/16 17:33, David Long wrote:
>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>> +#define MAX_INSN_SIZE 1
>>>>>> +#define MAX_STACK_SIZE 128
>>>>>
>>>>> Where is that value coming from? Because even on my 6502, I have a 256
>>>>> byte stack.
>>>>>
>>>>
>>>> Although I don't claim to know the original author's thoughts I would
>>>> guess it is based on the seven other existing implementations for
>>>> kprobes on various architectures, all of which appear to use either 64
>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>> whole stack.
> [...]
>>> My main worry is that whatever value you pick, it is always going to be
>>> wrong. This is used to preserve arguments that are passed on the stack,
>>> as opposed to passed by registers). We have no idea of what is getting
>>> passed there so saving nothing, 128 bytes or 2kB is about the same. It
>>> is always wrong.
>>>
>>> A much better solution would be to check the frame pointer, and copy the
>>> delta between FP and SP, assuming it fits inside the allocated buffer.
>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>> can't reliably execute it.
>>
>> Well, this is the way it works literally everywhere else. It is a documented
>> limitation (Documentation/kprobes.txt). Said documentation may need to be
>> changed along with the suggested fix.
>
> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> the arch code could always copy less but never more than MAX_STACK_SIZE.
> What we are proposing is that we should try to guess how much to copy
> based on the FP value (caller's frame) and, if larger than
> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> against the kprobes.txt document but at least it (a) may improve the
> performance slightly by avoiding unnecessary copy and (b) it avoids
> undefined behaviour if we ever encounter a jprobe with arguments passed
> on the stack beyond MAX_STACK_SIZE.
>
OK, it sounds like an improvement. I do worry a little about unexpected
side effects. I'm just asking if we can accept the existing code as now
complete enough (in that I believe it matches the other implementations)
and make this enhancement something for the next release cycle, allowing
the existing code to be exercised by a wider audience and providing
ample time to test the new modification? I'd hate to get stuck in a mode
where this patch gets repeatedly delayed for changes that go above and
beyond the original design.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-22 15:51 ` David Long
@ 2016-07-25 17:13 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-25 17:13 UTC (permalink / raw)
To: David Long
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> >>>On 21/07/16 17:33, David Long wrote:
> >>>>On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >>>>>On 08/07/16 17:35, David Long wrote:
> >>>>>>+#define MAX_INSN_SIZE 1
> >>>>>>+#define MAX_STACK_SIZE 128
> >>>>>
> >>>>>Where is that value coming from? Because even on my 6502, I have a 256
> >>>>>byte stack.
> >>>>>
> >>>>
> >>>>Although I don't claim to know the original author's thoughts I would
> >>>>guess it is based on the seven other existing implementations for
> >>>>kprobes on various architectures, all of which appear to use either 64
> >>>>or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> >>>>whole stack.
> >[...]
> >>>My main worry is that whatever value you pick, it is always going to be
> >>>wrong. This is used to preserve arguments that are passed on the stack,
> >>>as opposed to passed by registers). We have no idea of what is getting
> >>>passed there so saving nothing, 128 bytes or 2kB is about the same. It
> >>>is always wrong.
> >>>
> >>>A much better solution would be to check the frame pointer, and copy the
> >>>delta between FP and SP, assuming it fits inside the allocated buffer.
> >>>If it doesn't, or if FP is invalid, we just skip the hook, because we
> >>>can't reliably execute it.
> >>
> >>Well, this is the way it works literally everywhere else. It is a documented
> >>limitation (Documentation/kprobes.txt). Said documentation may need to be
> >>changed along with the suggested fix.
> >
> >The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >the arch code could always copy less but never more than MAX_STACK_SIZE.
> >What we are proposing is that we should try to guess how much to copy
> >based on the FP value (caller's frame) and, if larger than
> >MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >against the kprobes.txt document but at least it (a) may improve the
> >performance slightly by avoiding unnecessary copy and (b) it avoids
> >undefined behaviour if we ever encounter a jprobe with arguments passed
> >on the stack beyond MAX_STACK_SIZE.
>
> OK, it sounds like an improvement. I do worry a little about unexpected side
> effects.
You get more unexpected side effects by not saving/restoring the whole
stack. We looked into this on Friday and came to the conclusion that
there is no safe way for kprobes to know which arguments passed on the
stack should be preserved, at least not with the current API.
Basically the AArch64 PCS states that for arguments passed on the stack
(e.g. they can't fit in registers), the caller allocates memory for them
(on its own stack) and passes the pointer to the callee. Unfortunately,
the frame pointer seems to be decremented correspondingly to cover the
arguments, so we don't really have a way to tell how much to copy.
Copying just the caller's stack frame isn't safe either since a
callee/caller receiving such argument on the stack may passed it down to
a callee without copying (I couldn't find anything in the PCS stating
that this isn't allowed).
> I'm just asking if we can accept the existing code as now complete
> enough (in that I believe it matches the other implementations) and make
> this enhancement something for the next release cycle, allowing the existing
> code to be exercised by a wider audience and providing ample time to test
> the new modification? I'd hate to get stuck in a mode where this patch gets
> repeatedly delayed for changes that go above and beyond the original design.
The problem is that the original design was done on x86 for its PCS and
it doesn't always fit other architectures. So we could either ignore the
problem, hoping that no probed function requires argument passing on
stack or we copy all the valid data on the kernel stack:
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 61b49150dfa3..157fd0d0aa08 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -22,7 +22,7 @@
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 1
-#define MAX_STACK_SIZE 128
+#define MAX_STACK_SIZE THREAD_SIZE
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-25 17:13 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-25 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> >>>On 21/07/16 17:33, David Long wrote:
> >>>>On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >>>>>On 08/07/16 17:35, David Long wrote:
> >>>>>>+#define MAX_INSN_SIZE 1
> >>>>>>+#define MAX_STACK_SIZE 128
> >>>>>
> >>>>>Where is that value coming from? Because even on my 6502, I have a 256
> >>>>>byte stack.
> >>>>>
> >>>>
> >>>>Although I don't claim to know the original author's thoughts I would
> >>>>guess it is based on the seven other existing implementations for
> >>>>kprobes on various architectures, all of which appear to use either 64
> >>>>or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
> >>>>whole stack.
> >[...]
> >>>My main worry is that whatever value you pick, it is always going to be
> >>>wrong. This is used to preserve arguments that are passed on the stack,
> >>>as opposed to passed by registers). We have no idea of what is getting
> >>>passed there so saving nothing, 128 bytes or 2kB is about the same. It
> >>>is always wrong.
> >>>
> >>>A much better solution would be to check the frame pointer, and copy the
> >>>delta between FP and SP, assuming it fits inside the allocated buffer.
> >>>If it doesn't, or if FP is invalid, we just skip the hook, because we
> >>>can't reliably execute it.
> >>
> >>Well, this is the way it works literally everywhere else. It is a documented
> >>limitation (Documentation/kprobes.txt). Said documentation may need to be
> >>changed along with the suggested fix.
> >
> >The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >the arch code could always copy less but never more than MAX_STACK_SIZE.
> >What we are proposing is that we should try to guess how much to copy
> >based on the FP value (caller's frame) and, if larger than
> >MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >against the kprobes.txt document but at least it (a) may improve the
> >performance slightly by avoiding unnecessary copy and (b) it avoids
> >undefined behaviour if we ever encounter a jprobe with arguments passed
> >on the stack beyond MAX_STACK_SIZE.
>
> OK, it sounds like an improvement. I do worry a little about unexpected side
> effects.
You get more unexpected side effects by not saving/restoring the whole
stack. We looked into this on Friday and came to the conclusion that
there is no safe way for kprobes to know which arguments passed on the
stack should be preserved, at least not with the current API.
Basically the AArch64 PCS states that for arguments passed on the stack
(e.g. they can't fit in registers), the caller allocates memory for them
(on its own stack) and passes the pointer to the callee. Unfortunately,
the frame pointer seems to be decremented correspondingly to cover the
arguments, so we don't really have a way to tell how much to copy.
Copying just the caller's stack frame isn't safe either since a
callee/caller receiving such argument on the stack may passed it down to
a callee without copying (I couldn't find anything in the PCS stating
that this isn't allowed).
> I'm just asking if we can accept the existing code as now complete
> enough (in that I believe it matches the other implementations) and make
> this enhancement something for the next release cycle, allowing the existing
> code to be exercised by a wider audience and providing ample time to test
> the new modification? I'd hate to get stuck in a mode where this patch gets
> repeatedly delayed for changes that go above and beyond the original design.
The problem is that the original design was done on x86 for its PCS and
it doesn't always fit other architectures. So we could either ignore the
problem, hoping that no probed function requires argument passing on
stack or we copy all the valid data on the kernel stack:
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 61b49150dfa3..157fd0d0aa08 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -22,7 +22,7 @@
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 1
-#define MAX_STACK_SIZE 128
+#define MAX_STACK_SIZE THREAD_SIZE
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-25 17:13 ` Catalin Marinas
@ 2016-07-25 22:27 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-25 22:27 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Daniel Thompson, Huang Shijie, Dave P Martin,
Jisheng Zhang, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Yang Shi, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>
>>>>>>> Where is that value coming from? Because even on my 6502, I have a 256
>>>>>>> byte stack.
>>>>>>>
>>>>>>
>>>>>> Although I don't claim to know the original author's thoughts I would
>>>>>> guess it is based on the seven other existing implementations for
>>>>>> kprobes on various architectures, all of which appear to use either 64
>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>> whole stack.
>>> [...]
>>>>> My main worry is that whatever value you pick, it is always going to be
>>>>> wrong. This is used to preserve arguments that are passed on the stack,
>>>>> as opposed to passed by registers). We have no idea of what is getting
>>>>> passed there so saving nothing, 128 bytes or 2kB is about the same. It
>>>>> is always wrong.
>>>>>
>>>>> A much better solution would be to check the frame pointer, and copy the
>>>>> delta between FP and SP, assuming it fits inside the allocated buffer.
>>>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>>>> can't reliably execute it.
>>>>
>>>> Well, this is the way it works literally everywhere else. It is a documented
>>>> limitation (Documentation/kprobes.txt). Said documentation may need to be
>>>> changed along with the suggested fix.
>>>
>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
>>> the arch code could always copy less but never more than MAX_STACK_SIZE.
>>> What we are proposing is that we should try to guess how much to copy
>>> based on the FP value (caller's frame) and, if larger than
>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>> against the kprobes.txt document but at least it (a) may improve the
>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>> on the stack beyond MAX_STACK_SIZE.
>>
>> OK, it sounds like an improvement. I do worry a little about unexpected side
>> effects.
>
> You get more unexpected side effects by not saving/restoring the whole
> stack. We looked into this on Friday and came to the conclusion that
> there is no safe way for kprobes to know which arguments passed on the
> stack should be preserved, at least not with the current API.
>
> Basically the AArch64 PCS states that for arguments passed on the stack
> (e.g. they can't fit in registers), the caller allocates memory for them
> (on its own stack) and passes the pointer to the callee. Unfortunately,
> the frame pointer seems to be decremented correspondingly to cover the
> arguments, so we don't really have a way to tell how much to copy.
> Copying just the caller's stack frame isn't safe either since a
> callee/caller receiving such argument on the stack may passed it down to
> a callee without copying (I couldn't find anything in the PCS stating
> that this isn't allowed).
OK, so I think we're pretty much back to our starting point.
>
>> I'm just asking if we can accept the existing code as now complete
>> enough (in that I believe it matches the other implementations) and make
>> this enhancement something for the next release cycle, allowing the existing
>> code to be exercised by a wider audience and providing ample time to test
>> the new modification? I'd hate to get stuck in a mode where this patch gets
>> repeatedly delayed for changes that go above and beyond the original design.
>
> The problem is that the original design was done on x86 for its PCS and
> it doesn't always fit other architectures. So we could either ignore the
> problem, hoping that no probed function requires argument passing on
> stack or we copy all the valid data on the kernel stack:
>
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b49150dfa3..157fd0d0aa08 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,7 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
> +#define MAX_STACK_SIZE THREAD_SIZE
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
>
I doubt the ARM PCS is unusual. At any rate I'm certain there are other
architectures that pass aggregate parameters on the stack. I suspect
other RISC(-ish) architectures have similar PCS issues and I think this
is at least a big part of where this simple copy with a 64/128 limit
comes from, or at least why it continues to exist. That said, I'm not
enthusiastic about researching that assertion in detail as it could be
time consuming.
I think this (unchecked) limitation for stack frames is something users
of jprobes understand, or at least should understand from the
documentation. At any rate it doesn't sound like we have a way of
improving it, and I think that's OK.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-25 22:27 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-25 22:27 UTC (permalink / raw)
To: linux-arm-kernel
On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>
>>>>>>> Where is that value coming from? Because even on my 6502, I have a 256
>>>>>>> byte stack.
>>>>>>>
>>>>>>
>>>>>> Although I don't claim to know the original author's thoughts I would
>>>>>> guess it is based on the seven other existing implementations for
>>>>>> kprobes on various architectures, all of which appear to use either 64
>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>> whole stack.
>>> [...]
>>>>> My main worry is that whatever value you pick, it is always going to be
>>>>> wrong. This is used to preserve arguments that are passed on the stack,
>>>>> as opposed to passed by registers). We have no idea of what is getting
>>>>> passed there so saving nothing, 128 bytes or 2kB is about the same. It
>>>>> is always wrong.
>>>>>
>>>>> A much better solution would be to check the frame pointer, and copy the
>>>>> delta between FP and SP, assuming it fits inside the allocated buffer.
>>>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>>>> can't reliably execute it.
>>>>
>>>> Well, this is the way it works literally everywhere else. It is a documented
>>>> limitation (Documentation/kprobes.txt). Said documentation may need to be
>>>> changed along with the suggested fix.
>>>
>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
>>> the arch code could always copy less but never more than MAX_STACK_SIZE.
>>> What we are proposing is that we should try to guess how much to copy
>>> based on the FP value (caller's frame) and, if larger than
>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>> against the kprobes.txt document but at least it (a) may improve the
>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>> on the stack beyond MAX_STACK_SIZE.
>>
>> OK, it sounds like an improvement. I do worry a little about unexpected side
>> effects.
>
> You get more unexpected side effects by not saving/restoring the whole
> stack. We looked into this on Friday and came to the conclusion that
> there is no safe way for kprobes to know which arguments passed on the
> stack should be preserved, at least not with the current API.
>
> Basically the AArch64 PCS states that for arguments passed on the stack
> (e.g. they can't fit in registers), the caller allocates memory for them
> (on its own stack) and passes the pointer to the callee. Unfortunately,
> the frame pointer seems to be decremented correspondingly to cover the
> arguments, so we don't really have a way to tell how much to copy.
> Copying just the caller's stack frame isn't safe either since a
> callee/caller receiving such argument on the stack may passed it down to
> a callee without copying (I couldn't find anything in the PCS stating
> that this isn't allowed).
OK, so I think we're pretty much back to our starting point.
>
>> I'm just asking if we can accept the existing code as now complete
>> enough (in that I believe it matches the other implementations) and make
>> this enhancement something for the next release cycle, allowing the existing
>> code to be exercised by a wider audience and providing ample time to test
>> the new modification? I'd hate to get stuck in a mode where this patch gets
>> repeatedly delayed for changes that go above and beyond the original design.
>
> The problem is that the original design was done on x86 for its PCS and
> it doesn't always fit other architectures. So we could either ignore the
> problem, hoping that no probed function requires argument passing on
> stack or we copy all the valid data on the kernel stack:
>
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b49150dfa3..157fd0d0aa08 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,7 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
> +#define MAX_STACK_SIZE THREAD_SIZE
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
>
I doubt the ARM PCS is unusual. At any rate I'm certain there are other
architectures that pass aggregate parameters on the stack. I suspect
other RISC(-ish) architectures have similar PCS issues and I think this
is at least a big part of where this simple copy with a 64/128 limit
comes from, or at least why it continues to exist. That said, I'm not
enthusiastic about researching that assertion in detail as it could be
time consuming.
I think this (unchecked) limitation for stack frames is something users
of jprobes understand, or at least should understand from the
documentation. At any rate it doesn't sound like we have a way of
improving it, and I think that's OK.
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-25 17:13 ` Catalin Marinas
@ 2016-07-26 9:50 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-26 9:50 UTC (permalink / raw)
To: Catalin Marinas, David Long
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 25/07/16 18:13, Catalin Marinas wrote:
> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>> [...]
>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
>>> the arch code could always copy less but never more than MAX_STACK_SIZE.
>>> What we are proposing is that we should try to guess how much to copy
>>> based on the FP value (caller's frame) and, if larger than
>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>> against the kprobes.txt document but at least it (a) may improve the
>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>> on the stack beyond MAX_STACK_SIZE.
>>
>> OK, it sounds like an improvement. I do worry a little about unexpected side
>> effects.
>
> You get more unexpected side effects by not saving/restoring the whole
> stack. We looked into this on Friday and came to the conclusion that
> there is no safe way for kprobes to know which arguments passed on the
> stack should be preserved, at least not with the current API.
>
> Basically the AArch64 PCS states that for arguments passed on the stack
> (e.g. they can't fit in registers), the caller allocates memory for them
> (on its own stack) and passes the pointer to the callee. Unfortunately,
> the frame pointer seems to be decremented correspondingly to cover the
> arguments, so we don't really have a way to tell how much to copy.
> Copying just the caller's stack frame isn't safe either since a
> callee/caller receiving such argument on the stack may passed it down to
> a callee without copying (I couldn't find anything in the PCS stating
> that this isn't allowed).
The PCS[1] seems (at least to me) to be pretty clear that "the address
of the first stacked argument is defined to be the initial value of SP".
I think it is only the return value (when stacked via the x8 pointer)
that can be passed through an intermediate function in the way described
above. Isn't it OK for a jprobe to clobber this memory? The underlying
function will overwrite whatever the jprobe put there anyway.
Am I overlooking some additional detail in the PCS?
Daniel.
[1] Google presented me revision IHI 0055B (via infocenter.arm.com)
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-26 9:50 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-26 9:50 UTC (permalink / raw)
To: linux-arm-kernel
On 25/07/16 18:13, Catalin Marinas wrote:
> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>> [...]
>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
>>> the arch code could always copy less but never more than MAX_STACK_SIZE.
>>> What we are proposing is that we should try to guess how much to copy
>>> based on the FP value (caller's frame) and, if larger than
>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>> against the kprobes.txt document but at least it (a) may improve the
>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>> on the stack beyond MAX_STACK_SIZE.
>>
>> OK, it sounds like an improvement. I do worry a little about unexpected side
>> effects.
>
> You get more unexpected side effects by not saving/restoring the whole
> stack. We looked into this on Friday and came to the conclusion that
> there is no safe way for kprobes to know which arguments passed on the
> stack should be preserved, at least not with the current API.
>
> Basically the AArch64 PCS states that for arguments passed on the stack
> (e.g. they can't fit in registers), the caller allocates memory for them
> (on its own stack) and passes the pointer to the callee. Unfortunately,
> the frame pointer seems to be decremented correspondingly to cover the
> arguments, so we don't really have a way to tell how much to copy.
> Copying just the caller's stack frame isn't safe either since a
> callee/caller receiving such argument on the stack may passed it down to
> a callee without copying (I couldn't find anything in the PCS stating
> that this isn't allowed).
The PCS[1] seems (at least to me) to be pretty clear that "the address
of the first stacked argument is defined to be the initial value of SP".
I think it is only the return value (when stacked via the x8 pointer)
that can be passed through an intermediate function in the way described
above. Isn't it OK for a jprobe to clobber this memory? The underlying
function will overwrite whatever the jprobe put there anyway.
Am I overlooking some additional detail in the PCS?
Daniel.
[1] Google presented me revision IHI 0055B (via infocenter.arm.com)
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-26 9:50 ` Daniel Thompson
@ 2016-07-26 16:55 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-26 16:55 UTC (permalink / raw)
To: Daniel Thompson
Cc: David Long, Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> >>On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>>[...]
> >>>The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >>>the arch code could always copy less but never more than MAX_STACK_SIZE.
> >>>What we are proposing is that we should try to guess how much to copy
> >>>based on the FP value (caller's frame) and, if larger than
> >>>MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >>>against the kprobes.txt document but at least it (a) may improve the
> >>>performance slightly by avoiding unnecessary copy and (b) it avoids
> >>>undefined behaviour if we ever encounter a jprobe with arguments passed
> >>>on the stack beyond MAX_STACK_SIZE.
> >>
> >>OK, it sounds like an improvement. I do worry a little about unexpected side
> >>effects.
> >
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
>
> The PCS[1] seems (at least to me) to be pretty clear that "the address of
> the first stacked argument is defined to be the initial value of SP".
>
> I think it is only the return value (when stacked via the x8 pointer) that
> can be passed through an intermediate function in the way described above.
> Isn't it OK for a jprobe to clobber this memory? The underlying function
> will overwrite whatever the jprobe put there anyway.
>
> Am I overlooking some additional detail in the PCS?
I'm not sure I fully understand the PCS. I played with some random hacks
to test_kprobes.c (see below) and the address passed for a big struct
didn't look like the bottom of the stack.
diff --git a/kernel/test_kprobes.c b/kernel/test_kprobes.c
index 0dbab6d1acb4..6ed7be02a560 100644
--- a/kernel/test_kprobes.c
+++ b/kernel/test_kprobes.c
@@ -22,14 +22,18 @@
#define div_factor 3
+struct dummy {
+ char dummy_array[MAX_STACK_SIZE * 2];
+};
+
static u32 rand1, preh_val, posth_val, jph_val;
static int errors, handler_errors, num_tests;
-static u32 (*target)(u32 value);
+static u32 (*target)(u32 value, struct dummy d);
static u32 (*target2)(u32 value);
-static noinline u32 kprobe_target(u32 value)
+static noinline u32 kprobe_target(u32 value, struct dummy d)
{
- return (value / div_factor);
+ return (value / div_factor - d.dummy_array[0] + d.dummy_array[1]);
}
static int kp_pre_handler(struct kprobe *p, struct pt_regs *regs)
@@ -54,9 +58,11 @@ static struct kprobe kp = {
.post_handler = kp_post_handler
};
-static int test_kprobe(void)
+static int noinline test_kprobe(void)
{
int ret;
+ static struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_kprobe(&kp);
if (ret < 0) {
@@ -64,7 +70,8 @@ static int test_kprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
+ memset(&dummy, 10, sizeof(dummy));
unregister_kprobe(&kp);
if (preh_val == 0) {
@@ -111,6 +118,8 @@ static int test_kprobes(void)
{
int ret;
struct kprobe *kps[2] = {&kp, &kp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
kp.addr = NULL;
@@ -123,7 +132,7 @@ static int test_kprobes(void)
preh_val = 0;
posth_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (preh_val == 0) {
pr_err("kprobe pre_handler not called\n");
@@ -154,7 +163,7 @@ static int test_kprobes(void)
}
-static u32 j_kprobe_target(u32 value)
+static u32 j_kprobe_target(u32 value, struct dummy d)
{
if (value != rand1) {
handler_errors++;
@@ -174,6 +183,8 @@ static struct jprobe jp = {
static int test_jprobe(void)
{
int ret;
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_jprobe(&jp);
if (ret < 0) {
@@ -181,7 +192,7 @@ static int test_jprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
unregister_jprobe(&jp);
if (jph_val == 0) {
pr_err("jprobe handler not called\n");
@@ -200,6 +211,8 @@ static int test_jprobes(void)
{
int ret;
struct jprobe *jps[2] = {&jp, &jp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
jp.kp.addr = NULL;
@@ -211,7 +224,7 @@ static int test_jprobes(void)
}
jph_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (jph_val == 0) {
pr_err("jprobe handler not called\n");
handler_errors++;
@@ -262,6 +275,8 @@ static struct kretprobe rp = {
static int test_kretprobe(void)
{
int ret;
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_kretprobe(&rp);
if (ret < 0) {
@@ -269,7 +284,7 @@ static int test_kretprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
unregister_kretprobe(&rp);
if (krph_val != rand1) {
pr_err("kretprobe handler not called\n");
@@ -306,6 +321,8 @@ static int test_kretprobes(void)
{
int ret;
struct kretprobe *rps[2] = {&rp, &rp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
rp.kp.addr = NULL;
@@ -317,7 +334,7 @@ static int test_kretprobes(void)
}
krph_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (krph_val != rand1) {
pr_err("kretprobe handler not called\n");
handler_errors++;
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-26 16:55 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-26 16:55 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> >>On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>>[...]
> >>>The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >>>the arch code could always copy less but never more than MAX_STACK_SIZE.
> >>>What we are proposing is that we should try to guess how much to copy
> >>>based on the FP value (caller's frame) and, if larger than
> >>>MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >>>against the kprobes.txt document but at least it (a) may improve the
> >>>performance slightly by avoiding unnecessary copy and (b) it avoids
> >>>undefined behaviour if we ever encounter a jprobe with arguments passed
> >>>on the stack beyond MAX_STACK_SIZE.
> >>
> >>OK, it sounds like an improvement. I do worry a little about unexpected side
> >>effects.
> >
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
>
> The PCS[1] seems (at least to me) to be pretty clear that "the address of
> the first stacked argument is defined to be the initial value of SP".
>
> I think it is only the return value (when stacked via the x8 pointer) that
> can be passed through an intermediate function in the way described above.
> Isn't it OK for a jprobe to clobber this memory? The underlying function
> will overwrite whatever the jprobe put there anyway.
>
> Am I overlooking some additional detail in the PCS?
I'm not sure I fully understand the PCS. I played with some random hacks
to test_kprobes.c (see below) and the address passed for a big struct
didn't look like the bottom of the stack.
diff --git a/kernel/test_kprobes.c b/kernel/test_kprobes.c
index 0dbab6d1acb4..6ed7be02a560 100644
--- a/kernel/test_kprobes.c
+++ b/kernel/test_kprobes.c
@@ -22,14 +22,18 @@
#define div_factor 3
+struct dummy {
+ char dummy_array[MAX_STACK_SIZE * 2];
+};
+
static u32 rand1, preh_val, posth_val, jph_val;
static int errors, handler_errors, num_tests;
-static u32 (*target)(u32 value);
+static u32 (*target)(u32 value, struct dummy d);
static u32 (*target2)(u32 value);
-static noinline u32 kprobe_target(u32 value)
+static noinline u32 kprobe_target(u32 value, struct dummy d)
{
- return (value / div_factor);
+ return (value / div_factor - d.dummy_array[0] + d.dummy_array[1]);
}
static int kp_pre_handler(struct kprobe *p, struct pt_regs *regs)
@@ -54,9 +58,11 @@ static struct kprobe kp = {
.post_handler = kp_post_handler
};
-static int test_kprobe(void)
+static int noinline test_kprobe(void)
{
int ret;
+ static struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_kprobe(&kp);
if (ret < 0) {
@@ -64,7 +70,8 @@ static int test_kprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
+ memset(&dummy, 10, sizeof(dummy));
unregister_kprobe(&kp);
if (preh_val == 0) {
@@ -111,6 +118,8 @@ static int test_kprobes(void)
{
int ret;
struct kprobe *kps[2] = {&kp, &kp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
kp.addr = NULL;
@@ -123,7 +132,7 @@ static int test_kprobes(void)
preh_val = 0;
posth_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (preh_val == 0) {
pr_err("kprobe pre_handler not called\n");
@@ -154,7 +163,7 @@ static int test_kprobes(void)
}
-static u32 j_kprobe_target(u32 value)
+static u32 j_kprobe_target(u32 value, struct dummy d)
{
if (value != rand1) {
handler_errors++;
@@ -174,6 +183,8 @@ static struct jprobe jp = {
static int test_jprobe(void)
{
int ret;
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_jprobe(&jp);
if (ret < 0) {
@@ -181,7 +192,7 @@ static int test_jprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
unregister_jprobe(&jp);
if (jph_val == 0) {
pr_err("jprobe handler not called\n");
@@ -200,6 +211,8 @@ static int test_jprobes(void)
{
int ret;
struct jprobe *jps[2] = {&jp, &jp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
jp.kp.addr = NULL;
@@ -211,7 +224,7 @@ static int test_jprobes(void)
}
jph_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (jph_val == 0) {
pr_err("jprobe handler not called\n");
handler_errors++;
@@ -262,6 +275,8 @@ static struct kretprobe rp = {
static int test_kretprobe(void)
{
int ret;
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
ret = register_kretprobe(&rp);
if (ret < 0) {
@@ -269,7 +284,7 @@ static int test_kretprobe(void)
return ret;
}
- ret = target(rand1);
+ ret = target(rand1, dummy);
unregister_kretprobe(&rp);
if (krph_val != rand1) {
pr_err("kretprobe handler not called\n");
@@ -306,6 +321,8 @@ static int test_kretprobes(void)
{
int ret;
struct kretprobe *rps[2] = {&rp, &rp2};
+ struct dummy dummy;
+ memset(&dummy, 10, sizeof(dummy));
/* addr and flags should be cleard for reusing kprobe. */
rp.kp.addr = NULL;
@@ -317,7 +334,7 @@ static int test_kretprobes(void)
}
krph_val = 0;
- ret = target(rand1);
+ ret = target(rand1, dummy);
if (krph_val != rand1) {
pr_err("kretprobe handler not called\n");
handler_errors++;
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-26 9:50 ` Daniel Thompson
@ 2016-07-26 17:54 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2016-07-26 17:54 UTC (permalink / raw)
To: Daniel Thompson
Cc: Catalin Marinas, David Long, Petr Mladek, Zi Shen Lim,
Will Deacon, Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
>
> The PCS[1] seems (at least to me) to be pretty clear that "the
> address of the first stacked argument is defined to be the initial
> value of SP".
>
> I think it is only the return value (when stacked via the x8
> pointer) that can be passed through an intermediate function in the
> way described above. Isn't it OK for a jprobe to clobber this
> memory? The underlying function will overwrite whatever the jprobe
> put there anyway.
>
> Am I overlooking some additional detail in the PCS?
I suspect that the "initial value of SP" is simply meant to be relative to the
base of the region of stack reserved for callee parameters. While it also uses
the phrase "current stack-pointer value", I suspect that this is overly
prescriptive.
In practice, GCC allocates callee parameters *above* the frame record
for the caller, which is above the SP and FP. e.g. with:
----
#define NLARGE 128
struct large {
unsigned long v[NLARGE];
};
unsigned long __attribute__ ((noinline)) large_func(const struct large l)
{
return l.v[0];
}
int main(int argc, char *argv[])
{
struct large l = {
.v = { 1, },
};
return large_func(l);
}
----
Which yields the following assembly:
----
00000000004005d0 <large_func>:
4005d0: f81f0ff3 str x19, [sp,#-16]!
4005d4: aa0003f3 mov x19, x0
4005d8: f9400260 ldr x0, [x19]
4005dc: f84107f3 ldr x19, [sp],#16
4005e0: d65f03c0 ret
00000000004005e4 <main>:
4005e4: d12043ff sub sp, sp, #0x810
4005e8: a9bf7bfd stp x29, x30, [sp,#-16]!
4005ec: 910003fd mov x29, sp
4005f0: b9041fa0 str w0, [x29,#1052]
4005f4: f9020ba1 str x1, [x29,#1040]
4005f8: 911083a0 add x0, x29, #0x420
4005fc: d2808001 mov x1, #0x400 // #1024
400600: aa0103e2 mov x2, x1
400604: 52800001 mov w1, #0x0 // #0
400608: 97ffff92 bl 400450 <memset@plt>
40060c: d2800020 mov x0, #0x1 // #1
400610: f90213a0 str x0, [x29,#1056]
400614: 910043a0 add x0, x29, #0x10
400618: 911083a1 add x1, x29, #0x420
40061c: d2808002 mov x2, #0x400 // #1024
400620: 97ffff84 bl 400430 <memcpy@plt>
400624: 910043a0 add x0, x29, #0x10
400628: 97ffffea bl 4005d0 <large_func>
40062c: a8c17bfd ldp x29, x30, [sp],#16
400630: 912043ff add sp, sp, #0x810
400634: d65f03c0 ret
----
Please ignore the redundant copy GCC generates and copies; I can't seem
to convince it to not do that. The important part is that at 400614 the
argument to the function is the address immediately above the frame
record for main.
In local testing, it seems that additional locals can appear between the
frame record and argument.
Given this, callees can't rely on any relationship between their initial sp and
stacked arguments. Given that, I see no reason why an intermediary could not
simply pass the pointer on while creating further intermediary stack frames.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-26 17:54 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2016-07-26 17:54 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
>
> The PCS[1] seems (at least to me) to be pretty clear that "the
> address of the first stacked argument is defined to be the initial
> value of SP".
>
> I think it is only the return value (when stacked via the x8
> pointer) that can be passed through an intermediate function in the
> way described above. Isn't it OK for a jprobe to clobber this
> memory? The underlying function will overwrite whatever the jprobe
> put there anyway.
>
> Am I overlooking some additional detail in the PCS?
I suspect that the "initial value of SP" is simply meant to be relative to the
base of the region of stack reserved for callee parameters. While it also uses
the phrase "current stack-pointer value", I suspect that this is overly
prescriptive.
In practice, GCC allocates callee parameters *above* the frame record
for the caller, which is above the SP and FP. e.g. with:
----
#define NLARGE 128
struct large {
unsigned long v[NLARGE];
};
unsigned long __attribute__ ((noinline)) large_func(const struct large l)
{
return l.v[0];
}
int main(int argc, char *argv[])
{
struct large l = {
.v = { 1, },
};
return large_func(l);
}
----
Which yields the following assembly:
----
00000000004005d0 <large_func>:
4005d0: f81f0ff3 str x19, [sp,#-16]!
4005d4: aa0003f3 mov x19, x0
4005d8: f9400260 ldr x0, [x19]
4005dc: f84107f3 ldr x19, [sp],#16
4005e0: d65f03c0 ret
00000000004005e4 <main>:
4005e4: d12043ff sub sp, sp, #0x810
4005e8: a9bf7bfd stp x29, x30, [sp,#-16]!
4005ec: 910003fd mov x29, sp
4005f0: b9041fa0 str w0, [x29,#1052]
4005f4: f9020ba1 str x1, [x29,#1040]
4005f8: 911083a0 add x0, x29, #0x420
4005fc: d2808001 mov x1, #0x400 // #1024
400600: aa0103e2 mov x2, x1
400604: 52800001 mov w1, #0x0 // #0
400608: 97ffff92 bl 400450 <memset@plt>
40060c: d2800020 mov x0, #0x1 // #1
400610: f90213a0 str x0, [x29,#1056]
400614: 910043a0 add x0, x29, #0x10
400618: 911083a1 add x1, x29, #0x420
40061c: d2808002 mov x2, #0x400 // #1024
400620: 97ffff84 bl 400430 <memcpy@plt>
400624: 910043a0 add x0, x29, #0x10
400628: 97ffffea bl 4005d0 <large_func>
40062c: a8c17bfd ldp x29, x30, [sp],#16
400630: 912043ff add sp, sp, #0x810
400634: d65f03c0 ret
----
Please ignore the redundant copy GCC generates and copies; I can't seem
to convince it to not do that. The important part is that at 400614 the
argument to the function is the address immediately above the frame
record for main.
In local testing, it seems that additional locals can appear between the
frame record and argument.
Given this, callees can't rely on any relationship between their initial sp and
stacked arguments. Given that, I see no reason why an intermediary could not
simply pass the pointer on while creating further intermediary stack frames.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-26 16:55 ` Catalin Marinas
@ 2016-07-27 10:01 ` Dave Martin
-1 siblings, 0 replies; 147+ messages in thread
From: Dave Martin @ 2016-07-27 10:01 UTC (permalink / raw)
To: Catalin Marinas
Cc: Daniel Thompson, David Long, Mark Rutland, Yang Shi, Zi Shen Lim,
Will Deacon, Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Petr Mladek,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Mark Brown, Sandeepa Prabhu, William Cohen, Alex Bennée,
Adam Buchbinder, linux-arm-kernel, Ard Biesheuvel, linux-kernel,
James Morse, Masami Hiramatsu, Andrew Morton, Robin Murphy,
Jens Wiklander, Christoffer Dall
On Tue, Jul 26, 2016 at 05:55:43PM +0100, Catalin Marinas wrote:
> On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> > On 25/07/16 18:13, Catalin Marinas wrote:
> > >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> > >>OK, it sounds like an improvement. I do worry a little about unexpected side
> > >>effects.
> > >
> > >You get more unexpected side effects by not saving/restoring the whole
> > >stack. We looked into this on Friday and came to the conclusion that
> > >there is no safe way for kprobes to know which arguments passed on the
> > >stack should be preserved, at least not with the current API.
[...]
Jumping cheekily onto this thread, what if some function does this:
void go_on_jprobe_me()
{
}
void foo()
{
struct bar baz;
start_io(&baz);
/* ... */
go_on_jprobe_me();
end_io(&baz);
}
If some I/O is being done on baz asynchronously, via DMA or via another
thread, a jprobe implementation that attempts to save/restore the stack
beyond the arguments of the probed function is going to race with such
I/O and can corrupt data.
This is a risk whenever any thread triggers some other master to operate
on objects on the first thread's stack -- I/O is a contrived example, but
there are likely other ways similar asynchronous access can happen to
a thread's stack.
Worse, annotating go_on_jprobe_me() as un-jprobeable doesn't help --
the un-jprobeableness is a property not of the function itself, but
rather a property of the set of callers of that function. That set can
change at runtime (consider out-of-tree modules).
Cheers
---Dave
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 10:01 ` Dave Martin
0 siblings, 0 replies; 147+ messages in thread
From: Dave Martin @ 2016-07-27 10:01 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 26, 2016 at 05:55:43PM +0100, Catalin Marinas wrote:
> On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> > On 25/07/16 18:13, Catalin Marinas wrote:
> > >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> > >>OK, it sounds like an improvement. I do worry a little about unexpected side
> > >>effects.
> > >
> > >You get more unexpected side effects by not saving/restoring the whole
> > >stack. We looked into this on Friday and came to the conclusion that
> > >there is no safe way for kprobes to know which arguments passed on the
> > >stack should be preserved, at least not with the current API.
[...]
Jumping cheekily onto this thread, what if some function does this:
void go_on_jprobe_me()
{
}
void foo()
{
struct bar baz;
start_io(&baz);
/* ... */
go_on_jprobe_me();
end_io(&baz);
}
If some I/O is being done on baz asynchronously, via DMA or via another
thread, a jprobe implementation that attempts to save/restore the stack
beyond the arguments of the probed function is going to race with such
I/O and can corrupt data.
This is a risk whenever any thread triggers some other master to operate
on objects on the first thread's stack -- I/O is a contrived example, but
there are likely other ways similar asynchronous access can happen to
a thread's stack.
Worse, annotating go_on_jprobe_me() as un-jprobeable doesn't help --
the un-jprobeableness is a property not of the function itself, but
rather a property of the set of callers of that function. That set can
change at runtime (consider out-of-tree modules).
Cheers
---Dave
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-26 17:54 ` Mark Rutland
@ 2016-07-27 11:19 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, David Long, Petr Mladek, Zi Shen Lim,
Will Deacon, Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 26/07/16 18:54, Mark Rutland wrote:
> On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
>> On 25/07/16 18:13, Catalin Marinas wrote:
>>> You get more unexpected side effects by not saving/restoring the whole
>>> stack. We looked into this on Friday and came to the conclusion that
>>> there is no safe way for kprobes to know which arguments passed on the
>>> stack should be preserved, at least not with the current API.
>>>
>>> Basically the AArch64 PCS states that for arguments passed on the stack
>>> (e.g. they can't fit in registers), the caller allocates memory for them
>>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>>> the frame pointer seems to be decremented correspondingly to cover the
>>> arguments, so we don't really have a way to tell how much to copy.
>>> Copying just the caller's stack frame isn't safe either since a
>>> callee/caller receiving such argument on the stack may passed it down to
>>> a callee without copying (I couldn't find anything in the PCS stating
>>> that this isn't allowed).
>>
>> The PCS[1] seems (at least to me) to be pretty clear that "the
>> address of the first stacked argument is defined to be the initial
>> value of SP".
>>
>> I think it is only the return value (when stacked via the x8
>> pointer) that can be passed through an intermediate function in the
>> way described above. Isn't it OK for a jprobe to clobber this
>> memory? The underlying function will overwrite whatever the jprobe
>> put there anyway.
>>
>> Am I overlooking some additional detail in the PCS?
>
> I suspect that the "initial value of SP" is simply meant to be relative to the
> base of the region of stack reserved for callee parameters. While it also uses
> the phrase "current stack-pointer value", I suspect that this is overly
> prescriptive.
I don't think so. Whilst writing my reply of yesterday I forced stacked
arguments by creating a function with nine arguments (rather than large
values). The ninth argument is, as expected, passed to the callee based
on the value of the SP.
> In practice, GCC allocates callee parameters *above* the frame record
> for the caller, which is above the SP and FP. e.g. with:
>
> ----
> <snip>
> ----
> ----
> 00000000004005d0 <large_func>:
> 4005d0: f81f0ff3 str x19, [sp,#-16]!
> 4005d4: aa0003f3 mov x19, x0
> 4005d8: f9400260 ldr x0, [x19]
> 4005dc: f84107f3 ldr x19, [sp],#16
> 4005e0: d65f03c0 ret
> ...
> ----
Thanks for the example.
The large structure is not a stacked argument from the point of view of
the PCS parameter passing algorithm (which explicitly says how large
composite types will be allocated). Instead it looks like it has been
implicitly passed-by-reference and the caller makes this appear as
call-by-value by allocating from its own stack frame rather than from
the stacked argument space. The callee joins in by implicitly
dereferencing the pointer.
It is interesting to note that you force large_func() to stack its
arguments (by providing 8 dummy int arguments first) then the implicit
pass-by-reference behavior is still preserved even for a stacked
argument; large_func() ends up as:
~~~
large_func:
ldr x0, [sp]
ldr x0, [x0]
ret
~~~
Only thing is... I *still* haven't found anything in the AArch64 PCS
which describes this behavior.
I'm coming to believe that this is a mistake and this information (and
the threshold at which implicit pass-by-reference kicks in) should be
documented in section 7.
Or if you prefer the short version: I agree 100% with your analysis but
cannot find the document that supports it.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 11:19 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:19 UTC (permalink / raw)
To: linux-arm-kernel
On 26/07/16 18:54, Mark Rutland wrote:
> On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
>> On 25/07/16 18:13, Catalin Marinas wrote:
>>> You get more unexpected side effects by not saving/restoring the whole
>>> stack. We looked into this on Friday and came to the conclusion that
>>> there is no safe way for kprobes to know which arguments passed on the
>>> stack should be preserved, at least not with the current API.
>>>
>>> Basically the AArch64 PCS states that for arguments passed on the stack
>>> (e.g. they can't fit in registers), the caller allocates memory for them
>>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>>> the frame pointer seems to be decremented correspondingly to cover the
>>> arguments, so we don't really have a way to tell how much to copy.
>>> Copying just the caller's stack frame isn't safe either since a
>>> callee/caller receiving such argument on the stack may passed it down to
>>> a callee without copying (I couldn't find anything in the PCS stating
>>> that this isn't allowed).
>>
>> The PCS[1] seems (at least to me) to be pretty clear that "the
>> address of the first stacked argument is defined to be the initial
>> value of SP".
>>
>> I think it is only the return value (when stacked via the x8
>> pointer) that can be passed through an intermediate function in the
>> way described above. Isn't it OK for a jprobe to clobber this
>> memory? The underlying function will overwrite whatever the jprobe
>> put there anyway.
>>
>> Am I overlooking some additional detail in the PCS?
>
> I suspect that the "initial value of SP" is simply meant to be relative to the
> base of the region of stack reserved for callee parameters. While it also uses
> the phrase "current stack-pointer value", I suspect that this is overly
> prescriptive.
I don't think so. Whilst writing my reply of yesterday I forced stacked
arguments by creating a function with nine arguments (rather than large
values). The ninth argument is, as expected, passed to the callee based
on the value of the SP.
> In practice, GCC allocates callee parameters *above* the frame record
> for the caller, which is above the SP and FP. e.g. with:
>
> ----
> <snip>
> ----
> ----
> 00000000004005d0 <large_func>:
> 4005d0: f81f0ff3 str x19, [sp,#-16]!
> 4005d4: aa0003f3 mov x19, x0
> 4005d8: f9400260 ldr x0, [x19]
> 4005dc: f84107f3 ldr x19, [sp],#16
> 4005e0: d65f03c0 ret
> ...
> ----
Thanks for the example.
The large structure is not a stacked argument from the point of view of
the PCS parameter passing algorithm (which explicitly says how large
composite types will be allocated). Instead it looks like it has been
implicitly passed-by-reference and the caller makes this appear as
call-by-value by allocating from its own stack frame rather than from
the stacked argument space. The callee joins in by implicitly
dereferencing the pointer.
It is interesting to note that you force large_func() to stack its
arguments (by providing 8 dummy int arguments first) then the implicit
pass-by-reference behavior is still preserved even for a stacked
argument; large_func() ends up as:
~~~
large_func:
ldr x0, [sp]
ldr x0, [x0]
ret
~~~
Only thing is... I *still* haven't found anything in the AArch64 PCS
which describes this behavior.
I'm coming to believe that this is a mistake and this information (and
the threshold at which implicit pass-by-reference kicks in) should be
documented in section 7.
Or if you prefer the short version: I agree 100% with your analysis but
cannot find the document that supports it.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-27 11:19 ` Daniel Thompson
@ 2016-07-27 11:38 ` Dave Martin
-1 siblings, 0 replies; 147+ messages in thread
From: Dave Martin @ 2016-07-27 11:38 UTC (permalink / raw)
To: Daniel Thompson
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, David Long, Catalin Marinas,
Huang Shijie, Petr Mladek, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
[...]
> It is interesting to note that you force large_func() to stack its arguments
> (by providing 8 dummy int arguments first) then the implicit
> pass-by-reference behavior is still preserved even for a stacked argument;
> large_func() ends up as:
>
> ~~~
> large_func:
> ldr x0, [sp]
> ldr x0, [x0]
> ret
> ~~~
>
> Only thing is... I *still* haven't found anything in the AArch64 PCS which
> describes this behavior.
>
> I'm coming to believe that this is a mistake and this information (and the
> threshold at which implicit pass-by-reference kicks in) should be documented
> in section 7.
Is that answered by this?
B.3. If the argument type is a Composite Type that is larger than
16 bytes, then the argument is copied to memory allocated by the
caller and the argument is replaced by a pointer to the copy.
Experimenting with gcc's behaviour seems to back this up.
Cheers
---Dave
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 11:38 ` Dave Martin
0 siblings, 0 replies; 147+ messages in thread
From: Dave Martin @ 2016-07-27 11:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
[...]
> It is interesting to note that you force large_func() to stack its arguments
> (by providing 8 dummy int arguments first) then the implicit
> pass-by-reference behavior is still preserved even for a stacked argument;
> large_func() ends up as:
>
> ~~~
> large_func:
> ldr x0, [sp]
> ldr x0, [x0]
> ret
> ~~~
>
> Only thing is... I *still* haven't found anything in the AArch64 PCS which
> describes this behavior.
>
> I'm coming to believe that this is a mistake and this information (and the
> threshold at which implicit pass-by-reference kicks in) should be documented
> in section 7.
Is that answered by this?
B.3. If the argument type is a Composite Type that is larger than
16 bytes, then the argument is copied to memory allocated by the
caller and the argument is replaced by a pointer to the copy.
Experimenting with gcc's behaviour seems to back this up.
Cheers
---Dave
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-27 11:38 ` Dave Martin
@ 2016-07-27 11:42 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:42 UTC (permalink / raw)
To: Dave Martin
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, David Long, Catalin Marinas,
Huang Shijie, Petr Mladek, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On 27/07/16 12:38, Dave Martin wrote:
> On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
>
> [...]
>
>> It is interesting to note that you force large_func() to stack its arguments
>> (by providing 8 dummy int arguments first) then the implicit
>> pass-by-reference behavior is still preserved even for a stacked argument;
>> large_func() ends up as:
>>
>> ~~~
>> large_func:
>> ldr x0, [sp]
>> ldr x0, [x0]
>> ret
>> ~~~
>>
>> Only thing is... I *still* haven't found anything in the AArch64 PCS which
>> describes this behavior.
>>
>> I'm coming to believe that this is a mistake and this information (and the
>> threshold at which implicit pass-by-reference kicks in) should be documented
>> in section 7.
>
> Is that answered by this?
>
> B.3. If the argument type is a Composite Type that is larger than
> 16 bytes, then the argument is copied to memory allocated by the
> caller and the argument is replaced by a pointer to the copy.
>
> Experimenting with gcc's behaviour seems to back this up.
Absolutely answered by that. Thanks (and sorry for the noise)!
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 11:42 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:42 UTC (permalink / raw)
To: linux-arm-kernel
On 27/07/16 12:38, Dave Martin wrote:
> On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
>
> [...]
>
>> It is interesting to note that you force large_func() to stack its arguments
>> (by providing 8 dummy int arguments first) then the implicit
>> pass-by-reference behavior is still preserved even for a stacked argument;
>> large_func() ends up as:
>>
>> ~~~
>> large_func:
>> ldr x0, [sp]
>> ldr x0, [x0]
>> ret
>> ~~~
>>
>> Only thing is... I *still* haven't found anything in the AArch64 PCS which
>> describes this behavior.
>>
>> I'm coming to believe that this is a mistake and this information (and the
>> threshold at which implicit pass-by-reference kicks in) should be documented
>> in section 7.
>
> Is that answered by this?
>
> B.3. If the argument type is a Composite Type that is larger than
> 16 bytes, then the argument is copied to memory allocated by the
> caller and the argument is replaced by a pointer to the copy.
>
> Experimenting with gcc's behaviour seems to back this up.
Absolutely answered by that. Thanks (and sorry for the noise)!
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-25 22:27 ` David Long
@ 2016-07-27 11:50 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:50 UTC (permalink / raw)
To: David Long, Catalin Marinas
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 25/07/16 23:27, David Long wrote:
> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>>
>>>>>>>> Where is that value coming from? Because even on my 6502, I have
>>>>>>>> a 256
>>>>>>>> byte stack.
>>>>>>>>
>>>>>>>
>>>>>>> Although I don't claim to know the original author's thoughts I
>>>>>>> would
>>>>>>> guess it is based on the seven other existing implementations for
>>>>>>> kprobes on various architectures, all of which appear to use
>>>>>>> either 64
>>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>>> whole stack.
>>>> [...]
>>>>>> My main worry is that whatever value you pick, it is always going
>>>>>> to be
>>>>>> wrong. This is used to preserve arguments that are passed on the
>>>>>> stack,
>>>>>> as opposed to passed by registers). We have no idea of what is
>>>>>> getting
>>>>>> passed there so saving nothing, 128 bytes or 2kB is about the
>>>>>> same. It
>>>>>> is always wrong.
>>>>>>
>>>>>> A much better solution would be to check the frame pointer, and
>>>>>> copy the
>>>>>> delta between FP and SP, assuming it fits inside the allocated
>>>>>> buffer.
>>>>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>>>>> can't reliably execute it.
>>>>>
>>>>> Well, this is the way it works literally everywhere else. It is a
>>>>> documented
>>>>> limitation (Documentation/kprobes.txt). Said documentation may need
>>>>> to be
>>>>> changed along with the suggested fix.
>>>>
>>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That
>>>> means
>>>> the arch code could always copy less but never more than
>>>> MAX_STACK_SIZE.
>>>> What we are proposing is that we should try to guess how much to copy
>>>> based on the FP value (caller's frame) and, if larger than
>>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>>> against the kprobes.txt document but at least it (a) may improve the
>>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>>> on the stack beyond MAX_STACK_SIZE.
>>>
>>> OK, it sounds like an improvement. I do worry a little about
>>> unexpected side
>>> effects.
>>
>> You get more unexpected side effects by not saving/restoring the whole
>> stack. We looked into this on Friday and came to the conclusion that
>> there is no safe way for kprobes to know which arguments passed on the
>> stack should be preserved, at least not with the current API.
>>
>> Basically the AArch64 PCS states that for arguments passed on the stack
>> (e.g. they can't fit in registers), the caller allocates memory for them
>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>> the frame pointer seems to be decremented correspondingly to cover the
>> arguments, so we don't really have a way to tell how much to copy.
>> Copying just the caller's stack frame isn't safe either since a
>> callee/caller receiving such argument on the stack may passed it down to
>> a callee without copying (I couldn't find anything in the PCS stating
>> that this isn't allowed).
>
> OK, so I think we're pretty much back to our starting point.
>>
>>> I'm just asking if we can accept the existing code as now complete
>>> enough (in that I believe it matches the other implementations) and make
>>> this enhancement something for the next release cycle, allowing the
>>> existing
>>> code to be exercised by a wider audience and providing ample time to
>>> test
>>> the new modification? I'd hate to get stuck in a mode where this
>>> patch gets
>>> repeatedly delayed for changes that go above and beyond the original
>>> design.
>>
>> The problem is that the original design was done on x86 for its PCS and
>> it doesn't always fit other architectures. So we could either ignore the
>> problem, hoping that no probed function requires argument passing on
>> stack or we copy all the valid data on the kernel stack:
>>
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b49150dfa3..157fd0d0aa08 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,7 @@
>>
>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>> #define MAX_INSN_SIZE 1
>> -#define MAX_STACK_SIZE 128
>> +#define MAX_STACK_SIZE THREAD_SIZE
>>
>> #define flush_insn_slot(p) do { } while (0)
>> #define kretprobe_blacklist_size 0
>>
>
> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
> architectures that pass aggregate parameters on the stack. I suspect
> other RISC(-ish) architectures have similar PCS issues and I think this
> is at least a big part of where this simple copy with a 64/128 limit
> comes from, or at least why it continues to exist. That said, I'm not
> enthusiastic about researching that assertion in detail as it could be
> time consuming.
Given Mark shared a test program I *was* curious enough to take a look
at this.
The only architecture I can find that behaves like arm64 with the
implicit pass-by-reference described by Catalin/Mark is sparc64.
In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
hybrid approach where the first fragments of the structure are passed in
registers and the remainder on the stack.
> I think this (unchecked) limitation for stack frames is something users
> of jprobes understand, or at least should understand from the
> documentation. At any rate it doesn't sound like we have a way of
> improving it, and I think that's OK.
I don't think that this limitation could be inferred from the current
jprobes documentation. Most architectures (include arm64 when handling
>8 parameters) place arguments at the top of the stack. For these
architectures we need only consider the memory consumed by the (padded)
arguments in the function signature to determine if the jprobe will be safe.
On arm64 large structures/unions end up being allocated like normal
local variables and need not be near the top of the stack. This gives
the caller much greater flexibility and makes safety a property of the
caller not the callee.
So if it turns out to be too slow to store the whole of the stack then
it should at the very least be mentioned in the list of architecture
support that jprobes on functions that take structure/union arguments
>16 bytes are unsafe/unsupported.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 11:50 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-27 11:50 UTC (permalink / raw)
To: linux-arm-kernel
On 25/07/16 23:27, David Long wrote:
> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>>
>>>>>>>> Where is that value coming from? Because even on my 6502, I have
>>>>>>>> a 256
>>>>>>>> byte stack.
>>>>>>>>
>>>>>>>
>>>>>>> Although I don't claim to know the original author's thoughts I
>>>>>>> would
>>>>>>> guess it is based on the seven other existing implementations for
>>>>>>> kprobes on various architectures, all of which appear to use
>>>>>>> either 64
>>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>>> whole stack.
>>>> [...]
>>>>>> My main worry is that whatever value you pick, it is always going
>>>>>> to be
>>>>>> wrong. This is used to preserve arguments that are passed on the
>>>>>> stack,
>>>>>> as opposed to passed by registers). We have no idea of what is
>>>>>> getting
>>>>>> passed there so saving nothing, 128 bytes or 2kB is about the
>>>>>> same. It
>>>>>> is always wrong.
>>>>>>
>>>>>> A much better solution would be to check the frame pointer, and
>>>>>> copy the
>>>>>> delta between FP and SP, assuming it fits inside the allocated
>>>>>> buffer.
>>>>>> If it doesn't, or if FP is invalid, we just skip the hook, because we
>>>>>> can't reliably execute it.
>>>>>
>>>>> Well, this is the way it works literally everywhere else. It is a
>>>>> documented
>>>>> limitation (Documentation/kprobes.txt). Said documentation may need
>>>>> to be
>>>>> changed along with the suggested fix.
>>>>
>>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That
>>>> means
>>>> the arch code could always copy less but never more than
>>>> MAX_STACK_SIZE.
>>>> What we are proposing is that we should try to guess how much to copy
>>>> based on the FP value (caller's frame) and, if larger than
>>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>>> against the kprobes.txt document but at least it (a) may improve the
>>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>>> undefined behaviour if we ever encounter a jprobe with arguments passed
>>>> on the stack beyond MAX_STACK_SIZE.
>>>
>>> OK, it sounds like an improvement. I do worry a little about
>>> unexpected side
>>> effects.
>>
>> You get more unexpected side effects by not saving/restoring the whole
>> stack. We looked into this on Friday and came to the conclusion that
>> there is no safe way for kprobes to know which arguments passed on the
>> stack should be preserved, at least not with the current API.
>>
>> Basically the AArch64 PCS states that for arguments passed on the stack
>> (e.g. they can't fit in registers), the caller allocates memory for them
>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>> the frame pointer seems to be decremented correspondingly to cover the
>> arguments, so we don't really have a way to tell how much to copy.
>> Copying just the caller's stack frame isn't safe either since a
>> callee/caller receiving such argument on the stack may passed it down to
>> a callee without copying (I couldn't find anything in the PCS stating
>> that this isn't allowed).
>
> OK, so I think we're pretty much back to our starting point.
>>
>>> I'm just asking if we can accept the existing code as now complete
>>> enough (in that I believe it matches the other implementations) and make
>>> this enhancement something for the next release cycle, allowing the
>>> existing
>>> code to be exercised by a wider audience and providing ample time to
>>> test
>>> the new modification? I'd hate to get stuck in a mode where this
>>> patch gets
>>> repeatedly delayed for changes that go above and beyond the original
>>> design.
>>
>> The problem is that the original design was done on x86 for its PCS and
>> it doesn't always fit other architectures. So we could either ignore the
>> problem, hoping that no probed function requires argument passing on
>> stack or we copy all the valid data on the kernel stack:
>>
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b49150dfa3..157fd0d0aa08 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,7 @@
>>
>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>> #define MAX_INSN_SIZE 1
>> -#define MAX_STACK_SIZE 128
>> +#define MAX_STACK_SIZE THREAD_SIZE
>>
>> #define flush_insn_slot(p) do { } while (0)
>> #define kretprobe_blacklist_size 0
>>
>
> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
> architectures that pass aggregate parameters on the stack. I suspect
> other RISC(-ish) architectures have similar PCS issues and I think this
> is at least a big part of where this simple copy with a 64/128 limit
> comes from, or at least why it continues to exist. That said, I'm not
> enthusiastic about researching that assertion in detail as it could be
> time consuming.
Given Mark shared a test program I *was* curious enough to take a look
at this.
The only architecture I can find that behaves like arm64 with the
implicit pass-by-reference described by Catalin/Mark is sparc64.
In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
hybrid approach where the first fragments of the structure are passed in
registers and the remainder on the stack.
> I think this (unchecked) limitation for stack frames is something users
> of jprobes understand, or at least should understand from the
> documentation. At any rate it doesn't sound like we have a way of
> improving it, and I think that's OK.
I don't think that this limitation could be inferred from the current
jprobes documentation. Most architectures (include arm64 when handling
>8 parameters) place arguments at the top of the stack. For these
architectures we need only consider the memory consumed by the (padded)
arguments in the function signature to determine if the jprobe will be safe.
On arm64 large structures/unions end up being allocated like normal
local variables and need not be near the top of the stack. This gives
the caller much greater flexibility and makes safety a property of the
caller not the callee.
So if it turns out to be too slow to store the whole of the stack then
it should at the very least be mentioned in the list of architecture
support that jprobes on functions that take structure/union arguments
>16 bytes are unsafe/unsupported.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-27 11:19 ` Daniel Thompson
@ 2016-07-27 13:38 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2016-07-27 13:38 UTC (permalink / raw)
To: Daniel Thompson
Cc: Catalin Marinas, David Long, Petr Mladek, Zi Shen Lim,
Will Deacon, Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
> On 26/07/16 18:54, Mark Rutland wrote:
> >On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> >>On 25/07/16 18:13, Catalin Marinas wrote:
> >>>You get more unexpected side effects by not saving/restoring the whole
> >>>stack. We looked into this on Friday and came to the conclusion that
> >>>there is no safe way for kprobes to know which arguments passed on the
> >>>stack should be preserved, at least not with the current API.
> >>>
> >>>Basically the AArch64 PCS states that for arguments passed on the stack
> >>>(e.g. they can't fit in registers), the caller allocates memory for them
> >>>(on its own stack) and passes the pointer to the callee. Unfortunately,
> >>>the frame pointer seems to be decremented correspondingly to cover the
> >>>arguments, so we don't really have a way to tell how much to copy.
> >>>Copying just the caller's stack frame isn't safe either since a
> >>>callee/caller receiving such argument on the stack may passed it down to
> >>>a callee without copying (I couldn't find anything in the PCS stating
> >>>that this isn't allowed).
> >>
> >>The PCS[1] seems (at least to me) to be pretty clear that "the
> >>address of the first stacked argument is defined to be the initial
> >>value of SP".
> >>
> >>I think it is only the return value (when stacked via the x8
> >>pointer) that can be passed through an intermediate function in the
> >>way described above. Isn't it OK for a jprobe to clobber this
> >>memory? The underlying function will overwrite whatever the jprobe
> >>put there anyway.
> >>
> >>Am I overlooking some additional detail in the PCS?
> >
> >I suspect that the "initial value of SP" is simply meant to be relative to the
> >base of the region of stack reserved for callee parameters. While it also uses
> >the phrase "current stack-pointer value", I suspect that this is overly
> >prescriptive.
>
> I don't think so. Whilst writing my reply of yesterday I forced
> stacked arguments by creating a function with nine arguments (rather
> than large values). The ninth argument is, as expected, passed to
> the callee based on the value of the SP.
Ah. I'd failed to fully appreciate the distinction between large
structures (which get converted to pointers), and basic argument types
(including those converted pointers).
For basic argument types, I think you're right, and my wording above is
wrong.
However, for (large enough) structures I don't think we have any
guarantee as to their location.
Sorry for the confusion there!
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 13:38 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2016-07-27 13:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
> On 26/07/16 18:54, Mark Rutland wrote:
> >On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> >>On 25/07/16 18:13, Catalin Marinas wrote:
> >>>You get more unexpected side effects by not saving/restoring the whole
> >>>stack. We looked into this on Friday and came to the conclusion that
> >>>there is no safe way for kprobes to know which arguments passed on the
> >>>stack should be preserved, at least not with the current API.
> >>>
> >>>Basically the AArch64 PCS states that for arguments passed on the stack
> >>>(e.g. they can't fit in registers), the caller allocates memory for them
> >>>(on its own stack) and passes the pointer to the callee. Unfortunately,
> >>>the frame pointer seems to be decremented correspondingly to cover the
> >>>arguments, so we don't really have a way to tell how much to copy.
> >>>Copying just the caller's stack frame isn't safe either since a
> >>>callee/caller receiving such argument on the stack may passed it down to
> >>>a callee without copying (I couldn't find anything in the PCS stating
> >>>that this isn't allowed).
> >>
> >>The PCS[1] seems (at least to me) to be pretty clear that "the
> >>address of the first stacked argument is defined to be the initial
> >>value of SP".
> >>
> >>I think it is only the return value (when stacked via the x8
> >>pointer) that can be passed through an intermediate function in the
> >>way described above. Isn't it OK for a jprobe to clobber this
> >>memory? The underlying function will overwrite whatever the jprobe
> >>put there anyway.
> >>
> >>Am I overlooking some additional detail in the PCS?
> >
> >I suspect that the "initial value of SP" is simply meant to be relative to the
> >base of the region of stack reserved for callee parameters. While it also uses
> >the phrase "current stack-pointer value", I suspect that this is overly
> >prescriptive.
>
> I don't think so. Whilst writing my reply of yesterday I forced
> stacked arguments by creating a function with nine arguments (rather
> than large values). The ninth argument is, as expected, passed to
> the callee based on the value of the SP.
Ah. I'd failed to fully appreciate the distinction between large
structures (which get converted to pointers), and basic argument types
(including those converted pointers).
For basic argument types, I think you're right, and my wording above is
wrong.
However, for (large enough) structures I don't think we have any
guarantee as to their location.
Sorry for the confusion there!
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-27 11:50 ` Daniel Thompson
@ 2016-07-27 22:13 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-27 22:13 UTC (permalink / raw)
To: Daniel Thompson, Catalin Marinas
Cc: Mark Rutland, Petr Mladek, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, John Blackwood,
Pratyush Anand, Huang Shijie, Dave P Martin, Jisheng Zhang,
Vladimir Murzin, Steve Capper, Suzuki K Poulose, Marc Zyngier,
Yang Shi, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> On 25/07/16 23:27, David Long wrote:
>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>>>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>>>
>>>>>>>>> Where is that value coming from? Because even on my 6502, I have
>>>>>>>>> a 256
>>>>>>>>> byte stack.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Although I don't claim to know the original author's thoughts I
>>>>>>>> would
>>>>>>>> guess it is based on the seven other existing implementations for
>>>>>>>> kprobes on various architectures, all of which appear to use
>>>>>>>> either 64
>>>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>>>> whole stack.
>>>>> [...]
>>>>>>> My main worry is that whatever value you pick, it is always going
>>>>>>> to be
>>>>>>> wrong. This is used to preserve arguments that are passed on the
>>>>>>> stack,
>>>>>>> as opposed to passed by registers). We have no idea of what is
>>>>>>> getting
>>>>>>> passed there so saving nothing, 128 bytes or 2kB is about the
>>>>>>> same. It
>>>>>>> is always wrong.
>>>>>>>
>>>>>>> A much better solution would be to check the frame pointer, and
>>>>>>> copy the
>>>>>>> delta between FP and SP, assuming it fits inside the allocated
>>>>>>> buffer.
>>>>>>> If it doesn't, or if FP is invalid, we just skip the hook,
>>>>>>> because we
>>>>>>> can't reliably execute it.
>>>>>>
>>>>>> Well, this is the way it works literally everywhere else. It is a
>>>>>> documented
>>>>>> limitation (Documentation/kprobes.txt). Said documentation may need
>>>>>> to be
>>>>>> changed along with the suggested fix.
>>>>>
>>>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That
>>>>> means
>>>>> the arch code could always copy less but never more than
>>>>> MAX_STACK_SIZE.
>>>>> What we are proposing is that we should try to guess how much to copy
>>>>> based on the FP value (caller's frame) and, if larger than
>>>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>>>> against the kprobes.txt document but at least it (a) may improve the
>>>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>>>> undefined behaviour if we ever encounter a jprobe with arguments
>>>>> passed
>>>>> on the stack beyond MAX_STACK_SIZE.
>>>>
>>>> OK, it sounds like an improvement. I do worry a little about
>>>> unexpected side
>>>> effects.
>>>
>>> You get more unexpected side effects by not saving/restoring the whole
>>> stack. We looked into this on Friday and came to the conclusion that
>>> there is no safe way for kprobes to know which arguments passed on the
>>> stack should be preserved, at least not with the current API.
>>>
>>> Basically the AArch64 PCS states that for arguments passed on the stack
>>> (e.g. they can't fit in registers), the caller allocates memory for them
>>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>>> the frame pointer seems to be decremented correspondingly to cover the
>>> arguments, so we don't really have a way to tell how much to copy.
>>> Copying just the caller's stack frame isn't safe either since a
>>> callee/caller receiving such argument on the stack may passed it down to
>>> a callee without copying (I couldn't find anything in the PCS stating
>>> that this isn't allowed).
>>
>> OK, so I think we're pretty much back to our starting point.
>>>
>>>> I'm just asking if we can accept the existing code as now complete
>>>> enough (in that I believe it matches the other implementations) and
>>>> make
>>>> this enhancement something for the next release cycle, allowing the
>>>> existing
>>>> code to be exercised by a wider audience and providing ample time to
>>>> test
>>>> the new modification? I'd hate to get stuck in a mode where this
>>>> patch gets
>>>> repeatedly delayed for changes that go above and beyond the original
>>>> design.
>>>
>>> The problem is that the original design was done on x86 for its PCS and
>>> it doesn't always fit other architectures. So we could either ignore the
>>> problem, hoping that no probed function requires argument passing on
>>> stack or we copy all the valid data on the kernel stack:
>>>
>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>> b/arch/arm64/include/asm/kprobes.h
>>> index 61b49150dfa3..157fd0d0aa08 100644
>>> --- a/arch/arm64/include/asm/kprobes.h
>>> +++ b/arch/arm64/include/asm/kprobes.h
>>> @@ -22,7 +22,7 @@
>>>
>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>> #define MAX_INSN_SIZE 1
>>> -#define MAX_STACK_SIZE 128
>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>
>>> #define flush_insn_slot(p) do { } while (0)
>>> #define kretprobe_blacklist_size 0
>>>
>>
>> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
>> architectures that pass aggregate parameters on the stack. I suspect
>> other RISC(-ish) architectures have similar PCS issues and I think this
>> is at least a big part of where this simple copy with a 64/128 limit
>> comes from, or at least why it continues to exist. That said, I'm not
>> enthusiastic about researching that assertion in detail as it could be
>> time consuming.
>
> Given Mark shared a test program I *was* curious enough to take a look
> at this.
>
> The only architecture I can find that behaves like arm64 with the
> implicit pass-by-reference described by Catalin/Mark is sparc64.
>
> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> hybrid approach where the first fragments of the structure are passed in
> registers and the remainder on the stack.
>
That's interesting. It also looks like sparc64 does not copy any stack
for jprobes. I guess that approach at least makes it clear what will and
won't work.
>
>> I think this (unchecked) limitation for stack frames is something users
>> of jprobes understand, or at least should understand from the
>> documentation. At any rate it doesn't sound like we have a way of
>> improving it, and I think that's OK.
>
> I don't think that this limitation could be inferred from the current
> jprobes documentation. Most architectures (include arm64 when handling
> >8 parameters) place arguments at the top of the stack. For these
> architectures we need only consider the memory consumed by the (padded)
> arguments in the function signature to determine if the jprobe will be
> safe.
>
> On arm64 large structures/unions end up being allocated like normal
> local variables and need not be near the top of the stack. This gives
> the caller much greater flexibility and makes safety a property of the
> caller not the callee.
>
Yes, I had not fully appreciated how spread out the important parts of
the stack frame could be, before now.
> So if it turns out to be too slow to store the whole of the stack then
> it should at the very least be mentioned in the list of architecture
> support that jprobes on functions that take structure/union arguments
> >16 bytes are unsafe/unsupported.
>
>
> Daniel.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-27 22:13 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-07-27 22:13 UTC (permalink / raw)
To: linux-arm-kernel
On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> On 25/07/16 23:27, David Long wrote:
>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>> On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
>>>> On 07/22/2016 06:16 AM, Catalin Marinas wrote:
>>>>> On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
>>>>>> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
>>>>>>> On 21/07/16 17:33, David Long wrote:
>>>>>>>> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
>>>>>>>>> On 08/07/16 17:35, David Long wrote:
>>>>>>>>>> +#define MAX_INSN_SIZE 1
>>>>>>>>>> +#define MAX_STACK_SIZE 128
>>>>>>>>>
>>>>>>>>> Where is that value coming from? Because even on my 6502, I have
>>>>>>>>> a 256
>>>>>>>>> byte stack.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Although I don't claim to know the original author's thoughts I
>>>>>>>> would
>>>>>>>> guess it is based on the seven other existing implementations for
>>>>>>>> kprobes on various architectures, all of which appear to use
>>>>>>>> either 64
>>>>>>>> or 128 for MAX_STACK_SIZE. The code is not trying to duplicate the
>>>>>>>> whole stack.
>>>>> [...]
>>>>>>> My main worry is that whatever value you pick, it is always going
>>>>>>> to be
>>>>>>> wrong. This is used to preserve arguments that are passed on the
>>>>>>> stack,
>>>>>>> as opposed to passed by registers). We have no idea of what is
>>>>>>> getting
>>>>>>> passed there so saving nothing, 128 bytes or 2kB is about the
>>>>>>> same. It
>>>>>>> is always wrong.
>>>>>>>
>>>>>>> A much better solution would be to check the frame pointer, and
>>>>>>> copy the
>>>>>>> delta between FP and SP, assuming it fits inside the allocated
>>>>>>> buffer.
>>>>>>> If it doesn't, or if FP is invalid, we just skip the hook,
>>>>>>> because we
>>>>>>> can't reliably execute it.
>>>>>>
>>>>>> Well, this is the way it works literally everywhere else. It is a
>>>>>> documented
>>>>>> limitation (Documentation/kprobes.txt). Said documentation may need
>>>>>> to be
>>>>>> changed along with the suggested fix.
>>>>>
>>>>> The document states: "Up to MAX_STACK_SIZE bytes are copied". That
>>>>> means
>>>>> the arch code could always copy less but never more than
>>>>> MAX_STACK_SIZE.
>>>>> What we are proposing is that we should try to guess how much to copy
>>>>> based on the FP value (caller's frame) and, if larger than
>>>>> MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
>>>>> against the kprobes.txt document but at least it (a) may improve the
>>>>> performance slightly by avoiding unnecessary copy and (b) it avoids
>>>>> undefined behaviour if we ever encounter a jprobe with arguments
>>>>> passed
>>>>> on the stack beyond MAX_STACK_SIZE.
>>>>
>>>> OK, it sounds like an improvement. I do worry a little about
>>>> unexpected side
>>>> effects.
>>>
>>> You get more unexpected side effects by not saving/restoring the whole
>>> stack. We looked into this on Friday and came to the conclusion that
>>> there is no safe way for kprobes to know which arguments passed on the
>>> stack should be preserved, at least not with the current API.
>>>
>>> Basically the AArch64 PCS states that for arguments passed on the stack
>>> (e.g. they can't fit in registers), the caller allocates memory for them
>>> (on its own stack) and passes the pointer to the callee. Unfortunately,
>>> the frame pointer seems to be decremented correspondingly to cover the
>>> arguments, so we don't really have a way to tell how much to copy.
>>> Copying just the caller's stack frame isn't safe either since a
>>> callee/caller receiving such argument on the stack may passed it down to
>>> a callee without copying (I couldn't find anything in the PCS stating
>>> that this isn't allowed).
>>
>> OK, so I think we're pretty much back to our starting point.
>>>
>>>> I'm just asking if we can accept the existing code as now complete
>>>> enough (in that I believe it matches the other implementations) and
>>>> make
>>>> this enhancement something for the next release cycle, allowing the
>>>> existing
>>>> code to be exercised by a wider audience and providing ample time to
>>>> test
>>>> the new modification? I'd hate to get stuck in a mode where this
>>>> patch gets
>>>> repeatedly delayed for changes that go above and beyond the original
>>>> design.
>>>
>>> The problem is that the original design was done on x86 for its PCS and
>>> it doesn't always fit other architectures. So we could either ignore the
>>> problem, hoping that no probed function requires argument passing on
>>> stack or we copy all the valid data on the kernel stack:
>>>
>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>> b/arch/arm64/include/asm/kprobes.h
>>> index 61b49150dfa3..157fd0d0aa08 100644
>>> --- a/arch/arm64/include/asm/kprobes.h
>>> +++ b/arch/arm64/include/asm/kprobes.h
>>> @@ -22,7 +22,7 @@
>>>
>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>> #define MAX_INSN_SIZE 1
>>> -#define MAX_STACK_SIZE 128
>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>
>>> #define flush_insn_slot(p) do { } while (0)
>>> #define kretprobe_blacklist_size 0
>>>
>>
>> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
>> architectures that pass aggregate parameters on the stack. I suspect
>> other RISC(-ish) architectures have similar PCS issues and I think this
>> is at least a big part of where this simple copy with a 64/128 limit
>> comes from, or at least why it continues to exist. That said, I'm not
>> enthusiastic about researching that assertion in detail as it could be
>> time consuming.
>
> Given Mark shared a test program I *was* curious enough to take a look
> at this.
>
> The only architecture I can find that behaves like arm64 with the
> implicit pass-by-reference described by Catalin/Mark is sparc64.
>
> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> hybrid approach where the first fragments of the structure are passed in
> registers and the remainder on the stack.
>
That's interesting. It also looks like sparc64 does not copy any stack
for jprobes. I guess that approach at least makes it clear what will and
won't work.
>
>> I think this (unchecked) limitation for stack frames is something users
>> of jprobes understand, or at least should understand from the
>> documentation. At any rate it doesn't sound like we have a way of
>> improving it, and I think that's OK.
>
> I don't think that this limitation could be inferred from the current
> jprobes documentation. Most architectures (include arm64 when handling
> >8 parameters) place arguments at the top of the stack. For these
> architectures we need only consider the memory consumed by the (padded)
> arguments in the function signature to determine if the jprobe will be
> safe.
>
> On arm64 large structures/unions end up being allocated like normal
> local variables and need not be near the top of the stack. This gives
> the caller much greater flexibility and makes safety a property of the
> caller not the callee.
>
Yes, I had not fully appreciated how spread out the important parts of
the stack frame could be, before now.
> So if it turns out to be too slow to store the whole of the stack then
> it should at the very least be mentioned in the list of architecture
> support that jprobes on functions that take structure/union arguments
> >16 bytes are unsafe/unsupported.
>
>
> Daniel.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-27 22:13 ` David Long
@ 2016-07-28 14:40 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-28 14:40 UTC (permalink / raw)
To: David Long
Cc: Daniel Thompson, Mark Rutland, Yang Shi, Zi Shen Lim,
Will Deacon, Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> >On 25/07/16 23:27, David Long wrote:
> >>On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> >>>The problem is that the original design was done on x86 for its PCS and
> >>>it doesn't always fit other architectures. So we could either ignore the
> >>>problem, hoping that no probed function requires argument passing on
> >>>stack or we copy all the valid data on the kernel stack:
> >>>
> >>>diff --git a/arch/arm64/include/asm/kprobes.h
> >>>b/arch/arm64/include/asm/kprobes.h
> >>>index 61b49150dfa3..157fd0d0aa08 100644
> >>>--- a/arch/arm64/include/asm/kprobes.h
> >>>+++ b/arch/arm64/include/asm/kprobes.h
> >>>@@ -22,7 +22,7 @@
> >>>
> >>> #define __ARCH_WANT_KPROBES_INSN_SLOT
> >>> #define MAX_INSN_SIZE 1
> >>>-#define MAX_STACK_SIZE 128
> >>>+#define MAX_STACK_SIZE THREAD_SIZE
> >>>
> >>> #define flush_insn_slot(p) do { } while (0)
> >>> #define kretprobe_blacklist_size 0
> >>
> >>I doubt the ARM PCS is unusual. At any rate I'm certain there are other
> >>architectures that pass aggregate parameters on the stack. I suspect
> >>other RISC(-ish) architectures have similar PCS issues and I think this
> >>is at least a big part of where this simple copy with a 64/128 limit
> >>comes from, or at least why it continues to exist. That said, I'm not
> >>enthusiastic about researching that assertion in detail as it could be
> >>time consuming.
> >
> >Given Mark shared a test program I *was* curious enough to take a look
> >at this.
> >
> >The only architecture I can find that behaves like arm64 with the
> >implicit pass-by-reference described by Catalin/Mark is sparc64.
> >
> >In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> >hybrid approach where the first fragments of the structure are passed in
> >registers and the remainder on the stack.
>
> That's interesting. It also looks like sparc64 does not copy any stack for
> jprobes. I guess that approach at least makes it clear what will and won't
> work.
I suggest we do the same for arm64 - avoid the copying entirely as it's
not safe anyway. We don't know how much to copy, nor can we be sure it
is safe (see Dave's DMA to the stack example). This would need to be
documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
arm64 kprobes support.
There is also the case that Daniel was talking about - passing more than
8 arguments. I don't think it's worth handling this but we should at
least add a warning and skip the probe:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf9768588288..84e02606ec3d 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
long stack_ptr = kernel_stack_pointer(regs);
+ /* do not allow arguments passed on the stack */
+ if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
+ return 0;
+
kcb->jprobe_saved_regs = *regs;
/*
* As Linus pointed out, gcc assumes that the callee
Unfortunately, we don't really have a way to detect large composite
types passed as arguments, so we only have to rely on the documentation.
Can you please submit a patch that removes MAX_STACK_SIZE for arm64,
documents it and include the above hunk (once tested that it actually
does what it intends to).
Thanks.
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-28 14:40 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-07-28 14:40 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> >On 25/07/16 23:27, David Long wrote:
> >>On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> >>>The problem is that the original design was done on x86 for its PCS and
> >>>it doesn't always fit other architectures. So we could either ignore the
> >>>problem, hoping that no probed function requires argument passing on
> >>>stack or we copy all the valid data on the kernel stack:
> >>>
> >>>diff --git a/arch/arm64/include/asm/kprobes.h
> >>>b/arch/arm64/include/asm/kprobes.h
> >>>index 61b49150dfa3..157fd0d0aa08 100644
> >>>--- a/arch/arm64/include/asm/kprobes.h
> >>>+++ b/arch/arm64/include/asm/kprobes.h
> >>>@@ -22,7 +22,7 @@
> >>>
> >>> #define __ARCH_WANT_KPROBES_INSN_SLOT
> >>> #define MAX_INSN_SIZE 1
> >>>-#define MAX_STACK_SIZE 128
> >>>+#define MAX_STACK_SIZE THREAD_SIZE
> >>>
> >>> #define flush_insn_slot(p) do { } while (0)
> >>> #define kretprobe_blacklist_size 0
> >>
> >>I doubt the ARM PCS is unusual. At any rate I'm certain there are other
> >>architectures that pass aggregate parameters on the stack. I suspect
> >>other RISC(-ish) architectures have similar PCS issues and I think this
> >>is at least a big part of where this simple copy with a 64/128 limit
> >>comes from, or at least why it continues to exist. That said, I'm not
> >>enthusiastic about researching that assertion in detail as it could be
> >>time consuming.
> >
> >Given Mark shared a test program I *was* curious enough to take a look
> >at this.
> >
> >The only architecture I can find that behaves like arm64 with the
> >implicit pass-by-reference described by Catalin/Mark is sparc64.
> >
> >In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> >hybrid approach where the first fragments of the structure are passed in
> >registers and the remainder on the stack.
>
> That's interesting. It also looks like sparc64 does not copy any stack for
> jprobes. I guess that approach at least makes it clear what will and won't
> work.
I suggest we do the same for arm64 - avoid the copying entirely as it's
not safe anyway. We don't know how much to copy, nor can we be sure it
is safe (see Dave's DMA to the stack example). This would need to be
documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
arm64 kprobes support.
There is also the case that Daniel was talking about - passing more than
8 arguments. I don't think it's worth handling this but we should at
least add a warning and skip the probe:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf9768588288..84e02606ec3d 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
long stack_ptr = kernel_stack_pointer(regs);
+ /* do not allow arguments passed on the stack */
+ if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
+ return 0;
+
kcb->jprobe_saved_regs = *regs;
/*
* As Linus pointed out, gcc assumes that the callee
Unfortunately, we don't really have a way to detect large composite
types passed as arguments, so we only have to rely on the documentation.
Can you please submit a patch that removes MAX_STACK_SIZE for arm64,
documents it and include the above hunk (once tested that it actually
does what it intends to).
Thanks.
--
Catalin
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-28 14:40 ` Catalin Marinas
@ 2016-07-29 9:01 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-29 9:01 UTC (permalink / raw)
To: Catalin Marinas, David Long
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 28/07/16 15:40, Catalin Marinas wrote:
> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
>>> On 25/07/16 23:27, David Long wrote:
>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>>>> The problem is that the original design was done on x86 for its PCS and
>>>>> it doesn't always fit other architectures. So we could either ignore the
>>>>> problem, hoping that no probed function requires argument passing on
>>>>> stack or we copy all the valid data on the kernel stack:
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>>>> b/arch/arm64/include/asm/kprobes.h
>>>>> index 61b49150dfa3..157fd0d0aa08 100644
>>>>> --- a/arch/arm64/include/asm/kprobes.h
>>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>>> @@ -22,7 +22,7 @@
>>>>>
>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>>>> #define MAX_INSN_SIZE 1
>>>>> -#define MAX_STACK_SIZE 128
>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>>>
>>>>> #define flush_insn_slot(p) do { } while (0)
>>>>> #define kretprobe_blacklist_size 0
>>>>
>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
>>>> architectures that pass aggregate parameters on the stack. I suspect
>>>> other RISC(-ish) architectures have similar PCS issues and I think this
>>>> is at least a big part of where this simple copy with a 64/128 limit
>>>> comes from, or at least why it continues to exist. That said, I'm not
>>>> enthusiastic about researching that assertion in detail as it could be
>>>> time consuming.
>>>
>>> Given Mark shared a test program I *was* curious enough to take a look
>>> at this.
>>>
>>> The only architecture I can find that behaves like arm64 with the
>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
>>>
>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
>>> hybrid approach where the first fragments of the structure are passed in
>>> registers and the remainder on the stack.
>>
>> That's interesting. It also looks like sparc64 does not copy any stack for
>> jprobes. I guess that approach at least makes it clear what will and won't
>> work.
>
> I suggest we do the same for arm64 - avoid the copying entirely as it's
> not safe anyway. We don't know how much to copy, nor can we be sure it
> is safe (see Dave's DMA to the stack example). This would need to be
> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
> arm64 kprobes support.
>
> There is also the case that Daniel was talking about - passing more than
> 8 arguments. I don't think it's worth handling this
Its actually quite hard to document the (architecture specific) "no big
structures" *and* the "8 argument" limits. It ends up as something like:
Structures/unions >16 bytes must not be passed by value and the
size of all arguments, after padding each to an 8 byte boundary, must
be less than 64 bytes.
We cannot avoid tackling big structures through documentation but when
we impose additional limits like "only 8 arguments" we are swapping an
architecture neutral "gotcha" that affects almost all jprobes uses (and
can be inferred from the documentation) with an architecture specific one!
> but we should at
> least add a warning and skip the probe:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf9768588288..84e02606ec3d 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> long stack_ptr = kernel_stack_pointer(regs);
>
> + /* do not allow arguments passed on the stack */
> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
> + return 0;
> +
I don't really understand this test.
If we could reliably assume that the frame record was at the lowest
address within a stack frame then we could exploit that to store the
stacked arguments without risking overwriting volatile variables on the
stack.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-07-29 9:01 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-07-29 9:01 UTC (permalink / raw)
To: linux-arm-kernel
On 28/07/16 15:40, Catalin Marinas wrote:
> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
>>> On 25/07/16 23:27, David Long wrote:
>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>>>> The problem is that the original design was done on x86 for its PCS and
>>>>> it doesn't always fit other architectures. So we could either ignore the
>>>>> problem, hoping that no probed function requires argument passing on
>>>>> stack or we copy all the valid data on the kernel stack:
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>>>> b/arch/arm64/include/asm/kprobes.h
>>>>> index 61b49150dfa3..157fd0d0aa08 100644
>>>>> --- a/arch/arm64/include/asm/kprobes.h
>>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>>> @@ -22,7 +22,7 @@
>>>>>
>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>>>> #define MAX_INSN_SIZE 1
>>>>> -#define MAX_STACK_SIZE 128
>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>>>
>>>>> #define flush_insn_slot(p) do { } while (0)
>>>>> #define kretprobe_blacklist_size 0
>>>>
>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are other
>>>> architectures that pass aggregate parameters on the stack. I suspect
>>>> other RISC(-ish) architectures have similar PCS issues and I think this
>>>> is at least a big part of where this simple copy with a 64/128 limit
>>>> comes from, or at least why it continues to exist. That said, I'm not
>>>> enthusiastic about researching that assertion in detail as it could be
>>>> time consuming.
>>>
>>> Given Mark shared a test program I *was* curious enough to take a look
>>> at this.
>>>
>>> The only architecture I can find that behaves like arm64 with the
>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
>>>
>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
>>> hybrid approach where the first fragments of the structure are passed in
>>> registers and the remainder on the stack.
>>
>> That's interesting. It also looks like sparc64 does not copy any stack for
>> jprobes. I guess that approach at least makes it clear what will and won't
>> work.
>
> I suggest we do the same for arm64 - avoid the copying entirely as it's
> not safe anyway. We don't know how much to copy, nor can we be sure it
> is safe (see Dave's DMA to the stack example). This would need to be
> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
> arm64 kprobes support.
>
> There is also the case that Daniel was talking about - passing more than
> 8 arguments. I don't think it's worth handling this
Its actually quite hard to document the (architecture specific) "no big
structures" *and* the "8 argument" limits. It ends up as something like:
Structures/unions >16 bytes must not be passed by value and the
size of all arguments, after padding each to an 8 byte boundary, must
be less than 64 bytes.
We cannot avoid tackling big structures through documentation but when
we impose additional limits like "only 8 arguments" we are swapping an
architecture neutral "gotcha" that affects almost all jprobes uses (and
can be inferred from the documentation) with an architecture specific one!
> but we should at
> least add a warning and skip the probe:
>
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf9768588288..84e02606ec3d 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> long stack_ptr = kernel_stack_pointer(regs);
>
> + /* do not allow arguments passed on the stack */
> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
> + return 0;
> +
I don't really understand this test.
If we could reliably assume that the frame record was at the lowest
address within a stack frame then we could exploit that to store the
stacked arguments without risking overwriting volatile variables on the
stack.
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-07-29 9:01 ` Daniel Thompson
@ 2016-08-04 4:47 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-04 4:47 UTC (permalink / raw)
To: Daniel Thompson, Catalin Marinas
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall
On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> On 28/07/16 15:40, Catalin Marinas wrote:
>> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
>>>> On 25/07/16 23:27, David Long wrote:
>>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>>>>> The problem is that the original design was done on x86 for its
>>>>>> PCS and
>>>>>> it doesn't always fit other architectures. So we could either
>>>>>> ignore the
>>>>>> problem, hoping that no probed function requires argument passing on
>>>>>> stack or we copy all the valid data on the kernel stack:
>>>>>>
>>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>>>>> b/arch/arm64/include/asm/kprobes.h
>>>>>> index 61b49150dfa3..157fd0d0aa08 100644
>>>>>> --- a/arch/arm64/include/asm/kprobes.h
>>>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>>>> @@ -22,7 +22,7 @@
>>>>>>
>>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>>>>> #define MAX_INSN_SIZE 1
>>>>>> -#define MAX_STACK_SIZE 128
>>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>>>>
>>>>>> #define flush_insn_slot(p) do { } while (0)
>>>>>> #define kretprobe_blacklist_size 0
>>>>>
>>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are
>>>>> other
>>>>> architectures that pass aggregate parameters on the stack. I suspect
>>>>> other RISC(-ish) architectures have similar PCS issues and I think
>>>>> this
>>>>> is at least a big part of where this simple copy with a 64/128 limit
>>>>> comes from, or at least why it continues to exist. That said, I'm not
>>>>> enthusiastic about researching that assertion in detail as it could be
>>>>> time consuming.
>>>>
>>>> Given Mark shared a test program I *was* curious enough to take a look
>>>> at this.
>>>>
>>>> The only architecture I can find that behaves like arm64 with the
>>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
>>>>
>>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
>>>> hybrid approach where the first fragments of the structure are
>>>> passed in
>>>> registers and the remainder on the stack.
>>>
>>> That's interesting. It also looks like sparc64 does not copy any
>>> stack for
>>> jprobes. I guess that approach at least makes it clear what will and
>>> won't
>>> work.
>>
>> I suggest we do the same for arm64 - avoid the copying entirely as it's
>> not safe anyway. We don't know how much to copy, nor can we be sure it
>> is safe (see Dave's DMA to the stack example). This would need to be
>> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
>> arm64 kprobes support.
>>
>> There is also the case that Daniel was talking about - passing more than
>> 8 arguments. I don't think it's worth handling this
>
> Its actually quite hard to document the (architecture specific) "no big
> structures" *and* the "8 argument" limits. It ends up as something like:
>
> Structures/unions >16 bytes must not be passed by value and the
> size of all arguments, after padding each to an 8 byte boundary, must
> be less than 64 bytes.
>
> We cannot avoid tackling big structures through documentation but when
> we impose additional limits like "only 8 arguments" we are swapping an
> architecture neutral "gotcha" that affects almost all jprobes uses (and
> can be inferred from the documentation) with an architecture specific one!
>
See new patch below. The documentation change in it could use some scrutiny.
I've tested with one-off jprobes functions in a test module and I've
verified NET_TCPPROBE doesn't cause misbehavior.
>
> > but we should at
>> least add a warning and skip the probe:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf9768588288..84e02606ec3d 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe
>> *p, struct pt_regs *regs)
>> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> long stack_ptr = kernel_stack_pointer(regs);
>>
>> + /* do not allow arguments passed on the stack */
>> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
>> + return 0;
>> +
>
> I don't really understand this test.
>
> If we could reliably assume that the frame record was at the lowest
> address within a stack frame then we could exploit that to store the
> stacked arguments without risking overwriting volatile variables on the
> stack.
>
>
> Daniel.
>
I'm assuming the consensus is to not use the above snippet of code.
Thanks,
-dl
----------cut here--------
>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
From: "David A. Long" <dave.long@linaro.org>
Date: Thu, 4 Aug 2016 00:35:33 -0400
Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
Because the arm64 calling standard allows stacked function arguments to be
anywhere in the stack frame, do not attempt to duplicate the stack frame for
jprobes handler functions.
Signed-off-by: David A. Long <dave.long@linaro.org>
---
Documentation/kprobes.txt | 7 +++++++
arch/arm64/include/asm/kprobes.h | 2 --
arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
3 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 1f9b3e2..bd01839 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
or in registers. The jprobe will work in either case, so long as the
handler's prototype matches that of the probed function.
+Note that in some architectures (e.g.: arm64) the stack copy is not
+done, as the actual location of stacked parameters may be outside of
+a reasonable MAX_STACK_SIZE value and because that location cannot be
+determined by the jprobes code. In this case the jprobes user must be
+careful to make certain the calling signature of the function does
+not cause parameters to be passed on the stack.
+
1.3 Return Probes
1.3.1 How Does a Return Probe Work?
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 61b4915..1737aec 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -22,7 +22,6 @@
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 1
-#define MAX_STACK_SIZE 128
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
@@ -47,7 +46,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
struct kprobe_step_ctx ss_ctx;
struct pt_regs jprobe_saved_regs;
- char jprobes_stack[MAX_STACK_SIZE];
};
void arch_remove_kprobe(struct kprobe *);
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf97685..c6b0f40 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
-static inline unsigned long min_stack_size(unsigned long addr)
-{
- unsigned long size;
-
- if (on_irq_stack(addr, raw_smp_processor_id()))
- size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
- else
- size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
-
- return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
-}
-
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
struct jprobe *jp = container_of(p, struct jprobe, kp);
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long stack_ptr = kernel_stack_pointer(regs);
kcb->jprobe_saved_regs = *regs;
/*
- * As Linus pointed out, gcc assumes that the callee
- * owns the argument space and could overwrite it, e.g.
- * tailcall optimization. So, to be absolutely safe
- * we also save and restore enough stack bytes to cover
- * the argument area.
+ * Since we can't be sure where in the stack frame "stacked"
+ * pass-by-value arguments are stored we just don't try to
+ * duplicate any of the stack. Do not use jprobes on functions that
+ * use more than 64 bytes (after padding each to an 8 byte boundary)
+ * of arguments, or pass individual arguments larger than 16 bytes.
*/
- kasan_disable_current();
- memcpy(kcb->jprobes_stack, (void *)stack_ptr,
- min_stack_size(stack_ptr));
- kasan_enable_current();
instruction_pointer_set(regs, (unsigned long) jp->entry);
preempt_disable();
@@ -554,10 +537,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
}
unpause_graph_tracing();
*regs = kcb->jprobe_saved_regs;
- kasan_disable_current();
- memcpy((void *)stack_addr, kcb->jprobes_stack,
- min_stack_size(stack_addr));
- kasan_enable_current();
preempt_enable_no_resched();
return 1;
}
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-04 4:47 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-04 4:47 UTC (permalink / raw)
To: linux-arm-kernel
On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> On 28/07/16 15:40, Catalin Marinas wrote:
>> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
>>>> On 25/07/16 23:27, David Long wrote:
>>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>>>>>> The problem is that the original design was done on x86 for its
>>>>>> PCS and
>>>>>> it doesn't always fit other architectures. So we could either
>>>>>> ignore the
>>>>>> problem, hoping that no probed function requires argument passing on
>>>>>> stack or we copy all the valid data on the kernel stack:
>>>>>>
>>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
>>>>>> b/arch/arm64/include/asm/kprobes.h
>>>>>> index 61b49150dfa3..157fd0d0aa08 100644
>>>>>> --- a/arch/arm64/include/asm/kprobes.h
>>>>>> +++ b/arch/arm64/include/asm/kprobes.h
>>>>>> @@ -22,7 +22,7 @@
>>>>>>
>>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>>>>>> #define MAX_INSN_SIZE 1
>>>>>> -#define MAX_STACK_SIZE 128
>>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
>>>>>>
>>>>>> #define flush_insn_slot(p) do { } while (0)
>>>>>> #define kretprobe_blacklist_size 0
>>>>>
>>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are
>>>>> other
>>>>> architectures that pass aggregate parameters on the stack. I suspect
>>>>> other RISC(-ish) architectures have similar PCS issues and I think
>>>>> this
>>>>> is at least a big part of where this simple copy with a 64/128 limit
>>>>> comes from, or at least why it continues to exist. That said, I'm not
>>>>> enthusiastic about researching that assertion in detail as it could be
>>>>> time consuming.
>>>>
>>>> Given Mark shared a test program I *was* curious enough to take a look
>>>> at this.
>>>>
>>>> The only architecture I can find that behaves like arm64 with the
>>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
>>>>
>>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
>>>> hybrid approach where the first fragments of the structure are
>>>> passed in
>>>> registers and the remainder on the stack.
>>>
>>> That's interesting. It also looks like sparc64 does not copy any
>>> stack for
>>> jprobes. I guess that approach at least makes it clear what will and
>>> won't
>>> work.
>>
>> I suggest we do the same for arm64 - avoid the copying entirely as it's
>> not safe anyway. We don't know how much to copy, nor can we be sure it
>> is safe (see Dave's DMA to the stack example). This would need to be
>> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
>> arm64 kprobes support.
>>
>> There is also the case that Daniel was talking about - passing more than
>> 8 arguments. I don't think it's worth handling this
>
> Its actually quite hard to document the (architecture specific) "no big
> structures" *and* the "8 argument" limits. It ends up as something like:
>
> Structures/unions >16 bytes must not be passed by value and the
> size of all arguments, after padding each to an 8 byte boundary, must
> be less than 64 bytes.
>
> We cannot avoid tackling big structures through documentation but when
> we impose additional limits like "only 8 arguments" we are swapping an
> architecture neutral "gotcha" that affects almost all jprobes uses (and
> can be inferred from the documentation) with an architecture specific one!
>
See new patch below. The documentation change in it could use some scrutiny.
I've tested with one-off jprobes functions in a test module and I've
verified NET_TCPPROBE doesn't cause misbehavior.
>
> > but we should at
>> least add a warning and skip the probe:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf9768588288..84e02606ec3d 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe
>> *p, struct pt_regs *regs)
>> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> long stack_ptr = kernel_stack_pointer(regs);
>>
>> + /* do not allow arguments passed on the stack */
>> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
>> + return 0;
>> +
>
> I don't really understand this test.
>
> If we could reliably assume that the frame record was at the lowest
> address within a stack frame then we could exploit that to store the
> stacked arguments without risking overwriting volatile variables on the
> stack.
>
>
> Daniel.
>
I'm assuming the consensus is to not use the above snippet of code.
Thanks,
-dl
----------cut here--------
>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
From: "David A. Long" <dave.long@linaro.org>
Date: Thu, 4 Aug 2016 00:35:33 -0400
Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
Because the arm64 calling standard allows stacked function arguments to be
anywhere in the stack frame, do not attempt to duplicate the stack frame for
jprobes handler functions.
Signed-off-by: David A. Long <dave.long@linaro.org>
---
Documentation/kprobes.txt | 7 +++++++
arch/arm64/include/asm/kprobes.h | 2 --
arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
3 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 1f9b3e2..bd01839 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
or in registers. The jprobe will work in either case, so long as the
handler's prototype matches that of the probed function.
+Note that in some architectures (e.g.: arm64) the stack copy is not
+done, as the actual location of stacked parameters may be outside of
+a reasonable MAX_STACK_SIZE value and because that location cannot be
+determined by the jprobes code. In this case the jprobes user must be
+careful to make certain the calling signature of the function does
+not cause parameters to be passed on the stack.
+
1.3 Return Probes
1.3.1 How Does a Return Probe Work?
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 61b4915..1737aec 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -22,7 +22,6 @@
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 1
-#define MAX_STACK_SIZE 128
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
@@ -47,7 +46,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
struct kprobe_step_ctx ss_ctx;
struct pt_regs jprobe_saved_regs;
- char jprobes_stack[MAX_STACK_SIZE];
};
void arch_remove_kprobe(struct kprobe *);
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf97685..c6b0f40 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
static void __kprobes
post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
-static inline unsigned long min_stack_size(unsigned long addr)
-{
- unsigned long size;
-
- if (on_irq_stack(addr, raw_smp_processor_id()))
- size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
- else
- size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
-
- return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
-}
-
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
/* prepare insn slot */
@@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
struct jprobe *jp = container_of(p, struct jprobe, kp);
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long stack_ptr = kernel_stack_pointer(regs);
kcb->jprobe_saved_regs = *regs;
/*
- * As Linus pointed out, gcc assumes that the callee
- * owns the argument space and could overwrite it, e.g.
- * tailcall optimization. So, to be absolutely safe
- * we also save and restore enough stack bytes to cover
- * the argument area.
+ * Since we can't be sure where in the stack frame "stacked"
+ * pass-by-value arguments are stored we just don't try to
+ * duplicate any of the stack. Do not use jprobes on functions that
+ * use more than 64 bytes (after padding each to an 8 byte boundary)
+ * of arguments, or pass individual arguments larger than 16 bytes.
*/
- kasan_disable_current();
- memcpy(kcb->jprobes_stack, (void *)stack_ptr,
- min_stack_size(stack_ptr));
- kasan_enable_current();
instruction_pointer_set(regs, (unsigned long) jp->entry);
preempt_disable();
@@ -554,10 +537,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
}
unpause_graph_tracing();
*regs = kcb->jprobe_saved_regs;
- kasan_disable_current();
- memcpy((void *)stack_addr, kcb->jprobes_stack,
- min_stack_size(stack_addr));
- kasan_enable_current();
preempt_enable_no_resched();
return 1;
}
--
2.5.0
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-04 4:47 ` David Long
(?)
@ 2016-08-08 11:13 ` Daniel Thompson
-1 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-08-08 11:13 UTC (permalink / raw)
To: David Long, Catalin Marinas
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall,
sparclinux
On 04/08/16 05:47, David Long wrote:
> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> From: "David A. Long" <dave.long@linaro.org>
> Date: Thu, 4 Aug 2016 00:35:33 -0400
> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>
> Because the arm64 calling standard allows stacked function arguments to be
> anywhere in the stack frame, do not attempt to duplicate the stack frame for
> jprobes handler functions.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> ---
> Documentation/kprobes.txt | 7 +++++++
> arch/arm64/include/asm/kprobes.h | 2 --
> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> 3 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..bd01839 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
> or in registers. The jprobe will work in either case, so long as the
> handler's prototype matches that of the probed function.
>
> +Note that in some architectures (e.g.: arm64) the stack copy is not
Could sparc64 be added to this list?
For the sparc folks who are new to the thread, we've previously
established that the sparc64 ABI passes large structures by
allocating them from the caller's stack frame and passing a pointer
to the stack frame (i.e. arguments may not be at top of the stack).
We also noticed that sparc code does not save/restore anything from
the stack.
> +done, as the actual location of stacked parameters may be outside of
> +a reasonable MAX_STACK_SIZE value and because that location cannot be
> +determined by the jprobes code. In this case the jprobes user must be
> +careful to make certain the calling signature of the function does
> +not cause parameters to be passed on the stack.
> +
> 1.3 Return Probes
>
> 1.3.1 How Does a Return Probe Work?
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b4915..1737aec 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,6 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
> struct prev_kprobe prev_kprobe;
> struct kprobe_step_ctx ss_ctx;
> struct pt_regs jprobe_saved_regs;
> - char jprobes_stack[MAX_STACK_SIZE];
> };
>
> void arch_remove_kprobe(struct kprobe *);
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf97685..c6b0f40 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> -static inline unsigned long min_stack_size(unsigned long addr)
> -{
> - unsigned long size;
> -
> - if (on_irq_stack(addr, raw_smp_processor_id()))
> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> - else
> - size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> -
> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
> -}
> -
> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> {
> /* prepare insn slot */
> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> {
> struct jprobe *jp = container_of(p, struct jprobe, kp);
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> - long stack_ptr = kernel_stack_pointer(regs);
>
> kcb->jprobe_saved_regs = *regs;
> /*
> - * As Linus pointed out, gcc assumes that the callee
> - * owns the argument space and could overwrite it, e.g.
> - * tailcall optimization. So, to be absolutely safe
> - * we also save and restore enough stack bytes to cover
> - * the argument area.
> + * Since we can't be sure where in the stack frame "stacked"
> + * pass-by-value arguments are stored we just don't try to
> + * duplicate any of the stack.
> ...
> Do not use jprobes on functions that
> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> + * of arguments, or pass individual arguments larger than 16 bytes.
I like this wording. So much so that it really would be great to repeat
this in the Documentation/. Could this be included in the list of
architecture support/restrictions?
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 11:13 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-08-08 11:13 UTC (permalink / raw)
To: linux-arm-kernel
On 04/08/16 05:47, David Long wrote:
> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> From: "David A. Long" <dave.long@linaro.org>
> Date: Thu, 4 Aug 2016 00:35:33 -0400
> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>
> Because the arm64 calling standard allows stacked function arguments to be
> anywhere in the stack frame, do not attempt to duplicate the stack frame for
> jprobes handler functions.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> ---
> Documentation/kprobes.txt | 7 +++++++
> arch/arm64/include/asm/kprobes.h | 2 --
> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> 3 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..bd01839 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
> or in registers. The jprobe will work in either case, so long as the
> handler's prototype matches that of the probed function.
>
> +Note that in some architectures (e.g.: arm64) the stack copy is not
Could sparc64 be added to this list?
For the sparc folks who are new to the thread, we've previously
established that the sparc64 ABI passes large structures by
allocating them from the caller's stack frame and passing a pointer
to the stack frame (i.e. arguments may not be at top of the stack).
We also noticed that sparc code does not save/restore anything from
the stack.
> +done, as the actual location of stacked parameters may be outside of
> +a reasonable MAX_STACK_SIZE value and because that location cannot be
> +determined by the jprobes code. In this case the jprobes user must be
> +careful to make certain the calling signature of the function does
> +not cause parameters to be passed on the stack.
> +
> 1.3 Return Probes
>
> 1.3.1 How Does a Return Probe Work?
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b4915..1737aec 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,6 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
> struct prev_kprobe prev_kprobe;
> struct kprobe_step_ctx ss_ctx;
> struct pt_regs jprobe_saved_regs;
> - char jprobes_stack[MAX_STACK_SIZE];
> };
>
> void arch_remove_kprobe(struct kprobe *);
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf97685..c6b0f40 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> -static inline unsigned long min_stack_size(unsigned long addr)
> -{
> - unsigned long size;
> -
> - if (on_irq_stack(addr, raw_smp_processor_id()))
> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> - else
> - size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> -
> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
> -}
> -
> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> {
> /* prepare insn slot */
> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> {
> struct jprobe *jp = container_of(p, struct jprobe, kp);
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> - long stack_ptr = kernel_stack_pointer(regs);
>
> kcb->jprobe_saved_regs = *regs;
> /*
> - * As Linus pointed out, gcc assumes that the callee
> - * owns the argument space and could overwrite it, e.g.
> - * tailcall optimization. So, to be absolutely safe
> - * we also save and restore enough stack bytes to cover
> - * the argument area.
> + * Since we can't be sure where in the stack frame "stacked"
> + * pass-by-value arguments are stored we just don't try to
> + * duplicate any of the stack.
> ...
> Do not use jprobes on functions that
> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> + * of arguments, or pass individual arguments larger than 16 bytes.
I like this wording. So much so that it really would be great to repeat
this in the Documentation/. Could this be included in the list of
architecture support/restrictions?
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 11:13 ` Daniel Thompson
0 siblings, 0 replies; 147+ messages in thread
From: Daniel Thompson @ 2016-08-08 11:13 UTC (permalink / raw)
To: linux-arm-kernel
On 04/08/16 05:47, David Long wrote:
> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> From: "David A. Long" <dave.long@linaro.org>
> Date: Thu, 4 Aug 2016 00:35:33 -0400
> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>
> Because the arm64 calling standard allows stacked function arguments to be
> anywhere in the stack frame, do not attempt to duplicate the stack frame for
> jprobes handler functions.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
> ---
> Documentation/kprobes.txt | 7 +++++++
> arch/arm64/include/asm/kprobes.h | 2 --
> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> 3 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..bd01839 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
> or in registers. The jprobe will work in either case, so long as the
> handler's prototype matches that of the probed function.
>
> +Note that in some architectures (e.g.: arm64) the stack copy is not
Could sparc64 be added to this list?
For the sparc folks who are new to the thread, we've previously
established that the sparc64 ABI passes large structures by
allocating them from the caller's stack frame and passing a pointer
to the stack frame (i.e. arguments may not be at top of the stack).
We also noticed that sparc code does not save/restore anything from
the stack.
> +done, as the actual location of stacked parameters may be outside of
> +a reasonable MAX_STACK_SIZE value and because that location cannot be
> +determined by the jprobes code. In this case the jprobes user must be
> +careful to make certain the calling signature of the function does
> +not cause parameters to be passed on the stack.
> +
> 1.3 Return Probes
>
> 1.3.1 How Does a Return Probe Work?
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b4915..1737aec 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,6 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
> struct prev_kprobe prev_kprobe;
> struct kprobe_step_ctx ss_ctx;
> struct pt_regs jprobe_saved_regs;
> - char jprobes_stack[MAX_STACK_SIZE];
> };
>
> void arch_remove_kprobe(struct kprobe *);
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf97685..c6b0f40 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> -static inline unsigned long min_stack_size(unsigned long addr)
> -{
> - unsigned long size;
> -
> - if (on_irq_stack(addr, raw_smp_processor_id()))
> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> - else
> - size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> -
> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
> -}
> -
> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> {
> /* prepare insn slot */
> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> {
> struct jprobe *jp = container_of(p, struct jprobe, kp);
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> - long stack_ptr = kernel_stack_pointer(regs);
>
> kcb->jprobe_saved_regs = *regs;
> /*
> - * As Linus pointed out, gcc assumes that the callee
> - * owns the argument space and could overwrite it, e.g.
> - * tailcall optimization. So, to be absolutely safe
> - * we also save and restore enough stack bytes to cover
> - * the argument area.
> + * Since we can't be sure where in the stack frame "stacked"
> + * pass-by-value arguments are stored we just don't try to
> + * duplicate any of the stack.
> ...
> Do not use jprobes on functions that
> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> + * of arguments, or pass individual arguments larger than 16 bytes.
I like this wording. So much so that it really would be great to repeat
this in the Documentation/. Could this be included in the list of
architecture support/restrictions?
Daniel.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-08 11:13 ` Daniel Thompson
(?)
@ 2016-08-08 14:29 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-08 14:29 UTC (permalink / raw)
To: Daniel Thompson, Catalin Marinas
Cc: Mark Rutland, Yang Shi, Zi Shen Lim, Will Deacon,
Andrey Ryabinin, yalin wang, Li Bin, Jisheng Zhang,
John Blackwood, Pratyush Anand, Huang Shijie, Dave P Martin,
Petr Mladek, Vladimir Murzin, Steve Capper, Suzuki K Poulose,
Marc Zyngier, Mark Brown, Sandeepa Prabhu, William Cohen,
Alex Bennée, Adam Buchbinder, linux-arm-kernel,
Ard Biesheuvel, linux-kernel, James Morse, Masami Hiramatsu,
Andrew Morton, Robin Murphy, Jens Wiklander, Christoffer Dall,
sparclinux
On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> On 04/08/16 05:47, David Long wrote:
>> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>> From: "David A. Long" <dave.long@linaro.org>
>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>
>> Because the arm64 calling standard allows stacked function arguments
>> to be
>> anywhere in the stack frame, do not attempt to duplicate the stack
>> frame for
>> jprobes handler functions.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>> Documentation/kprobes.txt | 7 +++++++
>> arch/arm64/include/asm/kprobes.h | 2 --
>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>> index 1f9b3e2..bd01839 100644
>> --- a/Documentation/kprobes.txt
>> +++ b/Documentation/kprobes.txt
>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>> passed on the stack
>> or in registers. The jprobe will work in either case, so long as the
>> handler's prototype matches that of the probed function.
>>
>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>
> Could sparc64 be added to this list?
>
> For the sparc folks who are new to the thread, we've previously
> established that the sparc64 ABI passes large structures by
> allocating them from the caller's stack frame and passing a pointer
> to the stack frame (i.e. arguments may not be at top of the stack).
> We also noticed that sparc code does not save/restore anything from
> the stack.
>
I was reluctant to do that in the context of late changes to v4.8 for
arm64 but now that any changes for this are going in as a new patch it
would indeed be useful to get involvement from sparc maintainers.
>
>> +done, as the actual location of stacked parameters may be outside of
>> +a reasonable MAX_STACK_SIZE value and because that location cannot be
>> +determined by the jprobes code. In this case the jprobes user must be
>> +careful to make certain the calling signature of the function does
>> +not cause parameters to be passed on the stack.
>> +
>> 1.3 Return Probes
>>
>> 1.3.1 How Does a Return Probe Work?
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b4915..1737aec 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,6 @@
>>
>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>> #define MAX_INSN_SIZE 1
>> -#define MAX_STACK_SIZE 128
>>
>> #define flush_insn_slot(p) do { } while (0)
>> #define kretprobe_blacklist_size 0
>> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
>> struct prev_kprobe prev_kprobe;
>> struct kprobe_step_ctx ss_ctx;
>> struct pt_regs jprobe_saved_regs;
>> - char jprobes_stack[MAX_STACK_SIZE];
>> };
>>
>> void arch_remove_kprobe(struct kprobe *);
>> diff --git a/arch/arm64/kernel/probes/kprobes.c
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf97685..c6b0f40 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> static void __kprobes
>> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>>
>> -static inline unsigned long min_stack_size(unsigned long addr)
>> -{
>> - unsigned long size;
>> -
>> - if (on_irq_stack(addr, raw_smp_processor_id()))
>> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> - else
>> - size = (unsigned long)current_thread_info() + THREAD_START_SP
>> - addr;
>> -
>> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
>> -}
>> -
>> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> {
>> /* prepare insn slot */
>> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
>> *p, struct pt_regs *regs)
>> {
>> struct jprobe *jp = container_of(p, struct jprobe, kp);
>> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> - long stack_ptr = kernel_stack_pointer(regs);
>>
>> kcb->jprobe_saved_regs = *regs;
>> /*
>> - * As Linus pointed out, gcc assumes that the callee
>> - * owns the argument space and could overwrite it, e.g.
>> - * tailcall optimization. So, to be absolutely safe
>> - * we also save and restore enough stack bytes to cover
>> - * the argument area.
>> + * Since we can't be sure where in the stack frame "stacked"
>> + * pass-by-value arguments are stored we just don't try to
>> + * duplicate any of the stack.
> > ...
>> Do not use jprobes on functions
>> that
>> + * use more than 64 bytes (after padding each to an 8 byte boundary)
>> + * of arguments, or pass individual arguments larger than 16 bytes.
>
> I like this wording. So much so that it really would be great to repeat
> this in the Documentation/. Could this be included in the list of
> architecture support/restrictions?
>
Are you thinking specifically of the "5. Kprobes Features and
Limitations" section in Documentation/kprobes.txt?
>
> Daniel.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 14:29 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-08 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> On 04/08/16 05:47, David Long wrote:
>> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>> From: "David A. Long" <dave.long@linaro.org>
>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>
>> Because the arm64 calling standard allows stacked function arguments
>> to be
>> anywhere in the stack frame, do not attempt to duplicate the stack
>> frame for
>> jprobes handler functions.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>> Documentation/kprobes.txt | 7 +++++++
>> arch/arm64/include/asm/kprobes.h | 2 --
>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>> index 1f9b3e2..bd01839 100644
>> --- a/Documentation/kprobes.txt
>> +++ b/Documentation/kprobes.txt
>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>> passed on the stack
>> or in registers. The jprobe will work in either case, so long as the
>> handler's prototype matches that of the probed function.
>>
>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>
> Could sparc64 be added to this list?
>
> For the sparc folks who are new to the thread, we've previously
> established that the sparc64 ABI passes large structures by
> allocating them from the caller's stack frame and passing a pointer
> to the stack frame (i.e. arguments may not be at top of the stack).
> We also noticed that sparc code does not save/restore anything from
> the stack.
>
I was reluctant to do that in the context of late changes to v4.8 for
arm64 but now that any changes for this are going in as a new patch it
would indeed be useful to get involvement from sparc maintainers.
>
>> +done, as the actual location of stacked parameters may be outside of
>> +a reasonable MAX_STACK_SIZE value and because that location cannot be
>> +determined by the jprobes code. In this case the jprobes user must be
>> +careful to make certain the calling signature of the function does
>> +not cause parameters to be passed on the stack.
>> +
>> 1.3 Return Probes
>>
>> 1.3.1 How Does a Return Probe Work?
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b4915..1737aec 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,6 @@
>>
>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>> #define MAX_INSN_SIZE 1
>> -#define MAX_STACK_SIZE 128
>>
>> #define flush_insn_slot(p) do { } while (0)
>> #define kretprobe_blacklist_size 0
>> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
>> struct prev_kprobe prev_kprobe;
>> struct kprobe_step_ctx ss_ctx;
>> struct pt_regs jprobe_saved_regs;
>> - char jprobes_stack[MAX_STACK_SIZE];
>> };
>>
>> void arch_remove_kprobe(struct kprobe *);
>> diff --git a/arch/arm64/kernel/probes/kprobes.c
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf97685..c6b0f40 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> static void __kprobes
>> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>>
>> -static inline unsigned long min_stack_size(unsigned long addr)
>> -{
>> - unsigned long size;
>> -
>> - if (on_irq_stack(addr, raw_smp_processor_id()))
>> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> - else
>> - size = (unsigned long)current_thread_info() + THREAD_START_SP
>> - addr;
>> -
>> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
>> -}
>> -
>> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> {
>> /* prepare insn slot */
>> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
>> *p, struct pt_regs *regs)
>> {
>> struct jprobe *jp = container_of(p, struct jprobe, kp);
>> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> - long stack_ptr = kernel_stack_pointer(regs);
>>
>> kcb->jprobe_saved_regs = *regs;
>> /*
>> - * As Linus pointed out, gcc assumes that the callee
>> - * owns the argument space and could overwrite it, e.g.
>> - * tailcall optimization. So, to be absolutely safe
>> - * we also save and restore enough stack bytes to cover
>> - * the argument area.
>> + * Since we can't be sure where in the stack frame "stacked"
>> + * pass-by-value arguments are stored we just don't try to
>> + * duplicate any of the stack.
> > ...
>> Do not use jprobes on functions
>> that
>> + * use more than 64 bytes (after padding each to an 8 byte boundary)
>> + * of arguments, or pass individual arguments larger than 16 bytes.
>
> I like this wording. So much so that it really would be great to repeat
> this in the Documentation/. Could this be included in the list of
> architecture support/restrictions?
>
Are you thinking specifically of the "5. Kprobes Features and
Limitations" section in Documentation/kprobes.txt?
>
> Daniel.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 14:29 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-08 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> On 04/08/16 05:47, David Long wrote:
>> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>> From: "David A. Long" <dave.long@linaro.org>
>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>
>> Because the arm64 calling standard allows stacked function arguments
>> to be
>> anywhere in the stack frame, do not attempt to duplicate the stack
>> frame for
>> jprobes handler functions.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>> Documentation/kprobes.txt | 7 +++++++
>> arch/arm64/include/asm/kprobes.h | 2 --
>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>> index 1f9b3e2..bd01839 100644
>> --- a/Documentation/kprobes.txt
>> +++ b/Documentation/kprobes.txt
>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>> passed on the stack
>> or in registers. The jprobe will work in either case, so long as the
>> handler's prototype matches that of the probed function.
>>
>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>
> Could sparc64 be added to this list?
>
> For the sparc folks who are new to the thread, we've previously
> established that the sparc64 ABI passes large structures by
> allocating them from the caller's stack frame and passing a pointer
> to the stack frame (i.e. arguments may not be at top of the stack).
> We also noticed that sparc code does not save/restore anything from
> the stack.
>
I was reluctant to do that in the context of late changes to v4.8 for
arm64 but now that any changes for this are going in as a new patch it
would indeed be useful to get involvement from sparc maintainers.
>
>> +done, as the actual location of stacked parameters may be outside of
>> +a reasonable MAX_STACK_SIZE value and because that location cannot be
>> +determined by the jprobes code. In this case the jprobes user must be
>> +careful to make certain the calling signature of the function does
>> +not cause parameters to be passed on the stack.
>> +
>> 1.3 Return Probes
>>
>> 1.3.1 How Does a Return Probe Work?
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b4915..1737aec 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,6 @@
>>
>> #define __ARCH_WANT_KPROBES_INSN_SLOT
>> #define MAX_INSN_SIZE 1
>> -#define MAX_STACK_SIZE 128
>>
>> #define flush_insn_slot(p) do { } while (0)
>> #define kretprobe_blacklist_size 0
>> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
>> struct prev_kprobe prev_kprobe;
>> struct kprobe_step_ctx ss_ctx;
>> struct pt_regs jprobe_saved_regs;
>> - char jprobes_stack[MAX_STACK_SIZE];
>> };
>>
>> void arch_remove_kprobe(struct kprobe *);
>> diff --git a/arch/arm64/kernel/probes/kprobes.c
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf97685..c6b0f40 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> static void __kprobes
>> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>>
>> -static inline unsigned long min_stack_size(unsigned long addr)
>> -{
>> - unsigned long size;
>> -
>> - if (on_irq_stack(addr, raw_smp_processor_id()))
>> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
>> - else
>> - size = (unsigned long)current_thread_info() + THREAD_START_SP
>> - addr;
>> -
>> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
>> -}
>> -
>> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> {
>> /* prepare insn slot */
>> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
>> *p, struct pt_regs *regs)
>> {
>> struct jprobe *jp = container_of(p, struct jprobe, kp);
>> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> - long stack_ptr = kernel_stack_pointer(regs);
>>
>> kcb->jprobe_saved_regs = *regs;
>> /*
>> - * As Linus pointed out, gcc assumes that the callee
>> - * owns the argument space and could overwrite it, e.g.
>> - * tailcall optimization. So, to be absolutely safe
>> - * we also save and restore enough stack bytes to cover
>> - * the argument area.
>> + * Since we can't be sure where in the stack frame "stacked"
>> + * pass-by-value arguments are stored we just don't try to
>> + * duplicate any of the stack.
> > ...
>> Do not use jprobes on functions
>> that
>> + * use more than 64 bytes (after padding each to an 8 byte boundary)
>> + * of arguments, or pass individual arguments larger than 16 bytes.
>
> I like this wording. So much so that it really would be great to repeat
> this in the Documentation/. Could this be included in the list of
> architecture support/restrictions?
>
Are you thinking specifically of the "5. Kprobes Features and
Limitations" section in Documentation/kprobes.txt?
>
> Daniel.
>
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-04 4:47 ` David Long
@ 2016-08-08 22:19 ` Masami Hiramatsu
-1 siblings, 0 replies; 147+ messages in thread
From: Masami Hiramatsu @ 2016-08-08 22:19 UTC (permalink / raw)
To: David Long
Cc: Daniel Thompson, Catalin Marinas, Mark Rutland, Yang Shi,
Zi Shen Lim, Will Deacon, Andrey Ryabinin, yalin wang, Li Bin,
Jisheng Zhang, John Blackwood, Pratyush Anand, Huang Shijie,
Dave P Martin, Petr Mladek, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Thu, 4 Aug 2016 00:47:27 -0400
David Long <dave.long@linaro.org> wrote:
> On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> > On 28/07/16 15:40, Catalin Marinas wrote:
> >> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
> >>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> >>>> On 25/07/16 23:27, David Long wrote:
> >>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> >>>>>> The problem is that the original design was done on x86 for its
> >>>>>> PCS and
> >>>>>> it doesn't always fit other architectures. So we could either
> >>>>>> ignore the
> >>>>>> problem, hoping that no probed function requires argument passing on
> >>>>>> stack or we copy all the valid data on the kernel stack:
> >>>>>>
> >>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
> >>>>>> b/arch/arm64/include/asm/kprobes.h
> >>>>>> index 61b49150dfa3..157fd0d0aa08 100644
> >>>>>> --- a/arch/arm64/include/asm/kprobes.h
> >>>>>> +++ b/arch/arm64/include/asm/kprobes.h
> >>>>>> @@ -22,7 +22,7 @@
> >>>>>>
> >>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
> >>>>>> #define MAX_INSN_SIZE 1
> >>>>>> -#define MAX_STACK_SIZE 128
> >>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
> >>>>>>
> >>>>>> #define flush_insn_slot(p) do { } while (0)
> >>>>>> #define kretprobe_blacklist_size 0
> >>>>>
> >>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are
> >>>>> other
> >>>>> architectures that pass aggregate parameters on the stack. I suspect
> >>>>> other RISC(-ish) architectures have similar PCS issues and I think
> >>>>> this
> >>>>> is at least a big part of where this simple copy with a 64/128 limit
> >>>>> comes from, or at least why it continues to exist. That said, I'm not
> >>>>> enthusiastic about researching that assertion in detail as it could be
> >>>>> time consuming.
> >>>>
> >>>> Given Mark shared a test program I *was* curious enough to take a look
> >>>> at this.
> >>>>
> >>>> The only architecture I can find that behaves like arm64 with the
> >>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
> >>>>
> >>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> >>>> hybrid approach where the first fragments of the structure are
> >>>> passed in
> >>>> registers and the remainder on the stack.
> >>>
> >>> That's interesting. It also looks like sparc64 does not copy any
> >>> stack for
> >>> jprobes. I guess that approach at least makes it clear what will and
> >>> won't
> >>> work.
> >>
> >> I suggest we do the same for arm64 - avoid the copying entirely as it's
> >> not safe anyway. We don't know how much to copy, nor can we be sure it
> >> is safe (see Dave's DMA to the stack example). This would need to be
> >> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
> >> arm64 kprobes support.
> >>
> >> There is also the case that Daniel was talking about - passing more than
> >> 8 arguments. I don't think it's worth handling this
> >
> > Its actually quite hard to document the (architecture specific) "no big
> > structures" *and* the "8 argument" limits. It ends up as something like:
> >
> > Structures/unions >16 bytes must not be passed by value and the
> > size of all arguments, after padding each to an 8 byte boundary, must
> > be less than 64 bytes.
> >
> > We cannot avoid tackling big structures through documentation but when
> > we impose additional limits like "only 8 arguments" we are swapping an
> > architecture neutral "gotcha" that affects almost all jprobes uses (and
> > can be inferred from the documentation) with an architecture specific one!
> >
>
> See new patch below. The documentation change in it could use some scrutiny.
> I've tested with one-off jprobes functions in a test module and I've
> verified NET_TCPPROBE doesn't cause misbehavior.
>
> >
> > > but we should at
> >> least add a warning and skip the probe:
> >>
> >> diff --git a/arch/arm64/kernel/probes/kprobes.c
> >> b/arch/arm64/kernel/probes/kprobes.c
> >> index bf9768588288..84e02606ec3d 100644
> >> --- a/arch/arm64/kernel/probes/kprobes.c
> >> +++ b/arch/arm64/kernel/probes/kprobes.c
> >> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe
> >> *p, struct pt_regs *regs)
> >> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> >> long stack_ptr = kernel_stack_pointer(regs);
> >>
> >> + /* do not allow arguments passed on the stack */
> >> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
> >> + return 0;
> >> +
> >
> > I don't really understand this test.
> >
> > If we could reliably assume that the frame record was at the lowest
> > address within a stack frame then we could exploit that to store the
> > stacked arguments without risking overwriting volatile variables on the
> > stack.
> >
> >
> > Daniel.
> >
>
> I'm assuming the consensus is to not use the above snippet of code.
>
> Thanks,
> -dl
>
> ----------cut here--------
>
>
> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> From: "David A. Long" <dave.long@linaro.org>
> Date: Thu, 4 Aug 2016 00:35:33 -0400
> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>
> Because the arm64 calling standard allows stacked function arguments to be
> anywhere in the stack frame, do not attempt to duplicate the stack frame for
> jprobes handler functions.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
Looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
> ---
> Documentation/kprobes.txt | 7 +++++++
> arch/arm64/include/asm/kprobes.h | 2 --
> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> 3 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..bd01839 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
> or in registers. The jprobe will work in either case, so long as the
> handler's prototype matches that of the probed function.
>
> +Note that in some architectures (e.g.: arm64) the stack copy is not
> +done, as the actual location of stacked parameters may be outside of
> +a reasonable MAX_STACK_SIZE value and because that location cannot be
> +determined by the jprobes code. In this case the jprobes user must be
> +careful to make certain the calling signature of the function does
> +not cause parameters to be passed on the stack.
> +
> 1.3 Return Probes
>
> 1.3.1 How Does a Return Probe Work?
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b4915..1737aec 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,6 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
> struct prev_kprobe prev_kprobe;
> struct kprobe_step_ctx ss_ctx;
> struct pt_regs jprobe_saved_regs;
> - char jprobes_stack[MAX_STACK_SIZE];
> };
>
> void arch_remove_kprobe(struct kprobe *);
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf97685..c6b0f40 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> -static inline unsigned long min_stack_size(unsigned long addr)
> -{
> - unsigned long size;
> -
> - if (on_irq_stack(addr, raw_smp_processor_id()))
> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> - else
> - size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> -
> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
> -}
> -
> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> {
> /* prepare insn slot */
> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> {
> struct jprobe *jp = container_of(p, struct jprobe, kp);
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> - long stack_ptr = kernel_stack_pointer(regs);
>
> kcb->jprobe_saved_regs = *regs;
> /*
> - * As Linus pointed out, gcc assumes that the callee
> - * owns the argument space and could overwrite it, e.g.
> - * tailcall optimization. So, to be absolutely safe
> - * we also save and restore enough stack bytes to cover
> - * the argument area.
> + * Since we can't be sure where in the stack frame "stacked"
> + * pass-by-value arguments are stored we just don't try to
> + * duplicate any of the stack. Do not use jprobes on functions that
> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> + * of arguments, or pass individual arguments larger than 16 bytes.
> */
> - kasan_disable_current();
> - memcpy(kcb->jprobes_stack, (void *)stack_ptr,
> - min_stack_size(stack_ptr));
> - kasan_enable_current();
>
> instruction_pointer_set(regs, (unsigned long) jp->entry);
> preempt_disable();
> @@ -554,10 +537,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
> }
> unpause_graph_tracing();
> *regs = kcb->jprobe_saved_regs;
> - kasan_disable_current();
> - memcpy((void *)stack_addr, kcb->jprobes_stack,
> - min_stack_size(stack_addr));
> - kasan_enable_current();
> preempt_enable_no_resched();
> return 1;
> }
> --
> 2.5.0
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 22:19 ` Masami Hiramatsu
0 siblings, 0 replies; 147+ messages in thread
From: Masami Hiramatsu @ 2016-08-08 22:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 4 Aug 2016 00:47:27 -0400
David Long <dave.long@linaro.org> wrote:
> On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> > On 28/07/16 15:40, Catalin Marinas wrote:
> >> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
> >>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> >>>> On 25/07/16 23:27, David Long wrote:
> >>>>> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> >>>>>> The problem is that the original design was done on x86 for its
> >>>>>> PCS and
> >>>>>> it doesn't always fit other architectures. So we could either
> >>>>>> ignore the
> >>>>>> problem, hoping that no probed function requires argument passing on
> >>>>>> stack or we copy all the valid data on the kernel stack:
> >>>>>>
> >>>>>> diff --git a/arch/arm64/include/asm/kprobes.h
> >>>>>> b/arch/arm64/include/asm/kprobes.h
> >>>>>> index 61b49150dfa3..157fd0d0aa08 100644
> >>>>>> --- a/arch/arm64/include/asm/kprobes.h
> >>>>>> +++ b/arch/arm64/include/asm/kprobes.h
> >>>>>> @@ -22,7 +22,7 @@
> >>>>>>
> >>>>>> #define __ARCH_WANT_KPROBES_INSN_SLOT
> >>>>>> #define MAX_INSN_SIZE 1
> >>>>>> -#define MAX_STACK_SIZE 128
> >>>>>> +#define MAX_STACK_SIZE THREAD_SIZE
> >>>>>>
> >>>>>> #define flush_insn_slot(p) do { } while (0)
> >>>>>> #define kretprobe_blacklist_size 0
> >>>>>
> >>>>> I doubt the ARM PCS is unusual. At any rate I'm certain there are
> >>>>> other
> >>>>> architectures that pass aggregate parameters on the stack. I suspect
> >>>>> other RISC(-ish) architectures have similar PCS issues and I think
> >>>>> this
> >>>>> is at least a big part of where this simple copy with a 64/128 limit
> >>>>> comes from, or at least why it continues to exist. That said, I'm not
> >>>>> enthusiastic about researching that assertion in detail as it could be
> >>>>> time consuming.
> >>>>
> >>>> Given Mark shared a test program I *was* curious enough to take a look
> >>>> at this.
> >>>>
> >>>> The only architecture I can find that behaves like arm64 with the
> >>>> implicit pass-by-reference described by Catalin/Mark is sparc64.
> >>>>
> >>>> In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
> >>>> hybrid approach where the first fragments of the structure are
> >>>> passed in
> >>>> registers and the remainder on the stack.
> >>>
> >>> That's interesting. It also looks like sparc64 does not copy any
> >>> stack for
> >>> jprobes. I guess that approach at least makes it clear what will and
> >>> won't
> >>> work.
> >>
> >> I suggest we do the same for arm64 - avoid the copying entirely as it's
> >> not safe anyway. We don't know how much to copy, nor can we be sure it
> >> is safe (see Dave's DMA to the stack example). This would need to be
> >> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
> >> arm64 kprobes support.
> >>
> >> There is also the case that Daniel was talking about - passing more than
> >> 8 arguments. I don't think it's worth handling this
> >
> > Its actually quite hard to document the (architecture specific) "no big
> > structures" *and* the "8 argument" limits. It ends up as something like:
> >
> > Structures/unions >16 bytes must not be passed by value and the
> > size of all arguments, after padding each to an 8 byte boundary, must
> > be less than 64 bytes.
> >
> > We cannot avoid tackling big structures through documentation but when
> > we impose additional limits like "only 8 arguments" we are swapping an
> > architecture neutral "gotcha" that affects almost all jprobes uses (and
> > can be inferred from the documentation) with an architecture specific one!
> >
>
> See new patch below. The documentation change in it could use some scrutiny.
> I've tested with one-off jprobes functions in a test module and I've
> verified NET_TCPPROBE doesn't cause misbehavior.
>
> >
> > > but we should at
> >> least add a warning and skip the probe:
> >>
> >> diff --git a/arch/arm64/kernel/probes/kprobes.c
> >> b/arch/arm64/kernel/probes/kprobes.c
> >> index bf9768588288..84e02606ec3d 100644
> >> --- a/arch/arm64/kernel/probes/kprobes.c
> >> +++ b/arch/arm64/kernel/probes/kprobes.c
> >> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe
> >> *p, struct pt_regs *regs)
> >> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> >> long stack_ptr = kernel_stack_pointer(regs);
> >>
> >> + /* do not allow arguments passed on the stack */
> >> + if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
> >> + return 0;
> >> +
> >
> > I don't really understand this test.
> >
> > If we could reliably assume that the frame record was at the lowest
> > address within a stack frame then we could exploit that to store the
> > stacked arguments without risking overwriting volatile variables on the
> > stack.
> >
> >
> > Daniel.
> >
>
> I'm assuming the consensus is to not use the above snippet of code.
>
> Thanks,
> -dl
>
> ----------cut here--------
>
>
> From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> From: "David A. Long" <dave.long@linaro.org>
> Date: Thu, 4 Aug 2016 00:35:33 -0400
> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>
> Because the arm64 calling standard allows stacked function arguments to be
> anywhere in the stack frame, do not attempt to duplicate the stack frame for
> jprobes handler functions.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
Looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
> ---
> Documentation/kprobes.txt | 7 +++++++
> arch/arm64/include/asm/kprobes.h | 2 --
> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> 3 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..bd01839 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,13 @@ Note that the probed function's args may be passed on the stack
> or in registers. The jprobe will work in either case, so long as the
> handler's prototype matches that of the probed function.
>
> +Note that in some architectures (e.g.: arm64) the stack copy is not
> +done, as the actual location of stacked parameters may be outside of
> +a reasonable MAX_STACK_SIZE value and because that location cannot be
> +determined by the jprobes code. In this case the jprobes user must be
> +careful to make certain the calling signature of the function does
> +not cause parameters to be passed on the stack.
> +
> 1.3 Return Probes
>
> 1.3.1 How Does a Return Probe Work?
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 61b4915..1737aec 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -22,7 +22,6 @@
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> #define MAX_INSN_SIZE 1
> -#define MAX_STACK_SIZE 128
>
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
> @@ -47,7 +46,6 @@ struct kprobe_ctlblk {
> struct prev_kprobe prev_kprobe;
> struct kprobe_step_ctx ss_ctx;
> struct pt_regs jprobe_saved_regs;
> - char jprobes_stack[MAX_STACK_SIZE];
> };
>
> void arch_remove_kprobe(struct kprobe *);
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index bf97685..c6b0f40 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -41,18 +41,6 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> static void __kprobes
> post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>
> -static inline unsigned long min_stack_size(unsigned long addr)
> -{
> - unsigned long size;
> -
> - if (on_irq_stack(addr, raw_smp_processor_id()))
> - size = IRQ_STACK_PTR(raw_smp_processor_id()) - addr;
> - else
> - size = (unsigned long)current_thread_info() + THREAD_START_SP - addr;
> -
> - return min(size, FIELD_SIZEOF(struct kprobe_ctlblk, jprobes_stack));
> -}
> -
> static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> {
> /* prepare insn slot */
> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
> {
> struct jprobe *jp = container_of(p, struct jprobe, kp);
> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> - long stack_ptr = kernel_stack_pointer(regs);
>
> kcb->jprobe_saved_regs = *regs;
> /*
> - * As Linus pointed out, gcc assumes that the callee
> - * owns the argument space and could overwrite it, e.g.
> - * tailcall optimization. So, to be absolutely safe
> - * we also save and restore enough stack bytes to cover
> - * the argument area.
> + * Since we can't be sure where in the stack frame "stacked"
> + * pass-by-value arguments are stored we just don't try to
> + * duplicate any of the stack. Do not use jprobes on functions that
> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> + * of arguments, or pass individual arguments larger than 16 bytes.
> */
> - kasan_disable_current();
> - memcpy(kcb->jprobes_stack, (void *)stack_ptr,
> - min_stack_size(stack_ptr));
> - kasan_enable_current();
>
> instruction_pointer_set(regs, (unsigned long) jp->entry);
> preempt_disable();
> @@ -554,10 +537,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
> }
> unpause_graph_tracing();
> *regs = kcb->jprobe_saved_regs;
> - kasan_disable_current();
> - memcpy((void *)stack_addr, kcb->jprobes_stack,
> - min_stack_size(stack_addr));
> - kasan_enable_current();
> preempt_enable_no_resched();
> return 1;
> }
> --
> 2.5.0
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-08 14:29 ` David Long
(?)
@ 2016-08-08 22:49 ` Masami Hiramatsu
-1 siblings, 0 replies; 147+ messages in thread
From: Masami Hiramatsu @ 2016-08-08 22:49 UTC (permalink / raw)
To: David Long
Cc: Daniel Thompson, Catalin Marinas, Mark Rutland, Yang Shi,
Zi Shen Lim, Will Deacon, Andrey Ryabinin, yalin wang, Li Bin,
Jisheng Zhang, John Blackwood, Pratyush Anand, Huang Shijie,
Dave P Martin, Petr Mladek, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall, sparclinux
On Mon, 8 Aug 2016 10:29:05 -0400
David Long <dave.long@linaro.org> wrote:
> >> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
> >> *p, struct pt_regs *regs)
> >> {
> >> struct jprobe *jp = container_of(p, struct jprobe, kp);
> >> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> >> - long stack_ptr = kernel_stack_pointer(regs);
> >>
> >> kcb->jprobe_saved_regs = *regs;
> >> /*
> >> - * As Linus pointed out, gcc assumes that the callee
> >> - * owns the argument space and could overwrite it, e.g.
> >> - * tailcall optimization. So, to be absolutely safe
> >> - * we also save and restore enough stack bytes to cover
> >> - * the argument area.
> >> + * Since we can't be sure where in the stack frame "stacked"
> >> + * pass-by-value arguments are stored we just don't try to
> >> + * duplicate any of the stack.
> > > ...
> >> Do not use jprobes on functions
> >> that
> >> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> >> + * of arguments, or pass individual arguments larger than 16 bytes.
> >
> > I like this wording. So much so that it really would be great to repeat
> > this in the Documentation/. Could this be included in the list of
> > architecture support/restrictions?
> >
>
> Are you thinking specifically of the "5. Kprobes Features and
> Limitations" section in Documentation/kprobes.txt?
OK, That's a good idea :)
If you update the patch for that, please feel free to add my Ack.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 22:49 ` Masami Hiramatsu
0 siblings, 0 replies; 147+ messages in thread
From: Masami Hiramatsu @ 2016-08-08 22:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 8 Aug 2016 10:29:05 -0400
David Long <dave.long@linaro.org> wrote:
> >> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
> >> *p, struct pt_regs *regs)
> >> {
> >> struct jprobe *jp = container_of(p, struct jprobe, kp);
> >> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> >> - long stack_ptr = kernel_stack_pointer(regs);
> >>
> >> kcb->jprobe_saved_regs = *regs;
> >> /*
> >> - * As Linus pointed out, gcc assumes that the callee
> >> - * owns the argument space and could overwrite it, e.g.
> >> - * tailcall optimization. So, to be absolutely safe
> >> - * we also save and restore enough stack bytes to cover
> >> - * the argument area.
> >> + * Since we can't be sure where in the stack frame "stacked"
> >> + * pass-by-value arguments are stored we just don't try to
> >> + * duplicate any of the stack.
> > > ...
> >> Do not use jprobes on functions
> >> that
> >> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> >> + * of arguments, or pass individual arguments larger than 16 bytes.
> >
> > I like this wording. So much so that it really would be great to repeat
> > this in the Documentation/. Could this be included in the list of
> > architecture support/restrictions?
> >
>
> Are you thinking specifically of the "5. Kprobes Features and
> Limitations" section in Documentation/kprobes.txt?
OK, That's a good idea :)
If you update the patch for that, please feel free to add my Ack.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-08 22:49 ` Masami Hiramatsu
0 siblings, 0 replies; 147+ messages in thread
From: Masami Hiramatsu @ 2016-08-08 22:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 8 Aug 2016 10:29:05 -0400
David Long <dave.long@linaro.org> wrote:
> >> @@ -489,20 +477,15 @@ int __kprobes setjmp_pre_handler(struct kprobe
> >> *p, struct pt_regs *regs)
> >> {
> >> struct jprobe *jp = container_of(p, struct jprobe, kp);
> >> struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> >> - long stack_ptr = kernel_stack_pointer(regs);
> >>
> >> kcb->jprobe_saved_regs = *regs;
> >> /*
> >> - * As Linus pointed out, gcc assumes that the callee
> >> - * owns the argument space and could overwrite it, e.g.
> >> - * tailcall optimization. So, to be absolutely safe
> >> - * we also save and restore enough stack bytes to cover
> >> - * the argument area.
> >> + * Since we can't be sure where in the stack frame "stacked"
> >> + * pass-by-value arguments are stored we just don't try to
> >> + * duplicate any of the stack.
> > > ...
> >> Do not use jprobes on functions
> >> that
> >> + * use more than 64 bytes (after padding each to an 8 byte boundary)
> >> + * of arguments, or pass individual arguments larger than 16 bytes.
> >
> > I like this wording. So much so that it really would be great to repeat
> > this in the Documentation/. Could this be included in the list of
> > architecture support/restrictions?
> >
>
> Are you thinking specifically of the "5. Kprobes Features and
> Limitations" section in Documentation/kprobes.txt?
OK, That's a good idea :)
If you update the patch for that, please feel free to add my Ack.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-08 14:29 ` David Long
(?)
@ 2016-08-09 17:23 ` Catalin Marinas
-1 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-08-09 17:23 UTC (permalink / raw)
To: David Long
Cc: Daniel Thompson, Mark Rutland, Petr Mladek, Zi Shen Lim,
Will Deacon, sparclinux, Andrey Ryabinin, yalin wang, Li Bin,
Jisheng Zhang, John Blackwood, Pratyush Anand, Huang Shijie,
Dave P Martin, Yang Shi, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> >On 04/08/16 05:47, David Long wrote:
> >>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> >>From: "David A. Long" <dave.long@linaro.org>
> >>Date: Thu, 4 Aug 2016 00:35:33 -0400
> >>Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
> >>
> >>Because the arm64 calling standard allows stacked function arguments
> >>to be
> >>anywhere in the stack frame, do not attempt to duplicate the stack
> >>frame for
> >>jprobes handler functions.
> >>
> >>Signed-off-by: David A. Long <dave.long@linaro.org>
> >>---
> >> Documentation/kprobes.txt | 7 +++++++
> >> arch/arm64/include/asm/kprobes.h | 2 --
> >> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> >> 3 files changed, 12 insertions(+), 28 deletions(-)
> >>
> >>diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> >>index 1f9b3e2..bd01839 100644
> >>--- a/Documentation/kprobes.txt
> >>+++ b/Documentation/kprobes.txt
> >>@@ -103,6 +103,13 @@ Note that the probed function's args may be
> >>passed on the stack
> >> or in registers. The jprobe will work in either case, so long as the
> >> handler's prototype matches that of the probed function.
> >>
> >>+Note that in some architectures (e.g.: arm64) the stack copy is not
> >
> >Could sparc64 be added to this list?
> >
> > For the sparc folks who are new to the thread, we've previously
> > established that the sparc64 ABI passes large structures by
> > allocating them from the caller's stack frame and passing a pointer
> > to the stack frame (i.e. arguments may not be at top of the stack).
> > We also noticed that sparc code does not save/restore anything from
> > the stack.
>
> I was reluctant to do that in the context of late changes to v4.8 for arm64
> but now that any changes for this are going in as a new patch it would
> indeed be useful to get involvement from sparc maintainers.
I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
Whether you can mention sparc64 as well, it depends on the sparc
maintainers. You can either cc them or send the series as two patches,
one for documentation and the other for arm64.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-09 17:23 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-08-09 17:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> >On 04/08/16 05:47, David Long wrote:
> >>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> >>From: "David A. Long" <dave.long@linaro.org>
> >>Date: Thu, 4 Aug 2016 00:35:33 -0400
> >>Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
> >>
> >>Because the arm64 calling standard allows stacked function arguments
> >>to be
> >>anywhere in the stack frame, do not attempt to duplicate the stack
> >>frame for
> >>jprobes handler functions.
> >>
> >>Signed-off-by: David A. Long <dave.long@linaro.org>
> >>---
> >> Documentation/kprobes.txt | 7 +++++++
> >> arch/arm64/include/asm/kprobes.h | 2 --
> >> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> >> 3 files changed, 12 insertions(+), 28 deletions(-)
> >>
> >>diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> >>index 1f9b3e2..bd01839 100644
> >>--- a/Documentation/kprobes.txt
> >>+++ b/Documentation/kprobes.txt
> >>@@ -103,6 +103,13 @@ Note that the probed function's args may be
> >>passed on the stack
> >> or in registers. The jprobe will work in either case, so long as the
> >> handler's prototype matches that of the probed function.
> >>
> >>+Note that in some architectures (e.g.: arm64) the stack copy is not
> >
> >Could sparc64 be added to this list?
> >
> > For the sparc folks who are new to the thread, we've previously
> > established that the sparc64 ABI passes large structures by
> > allocating them from the caller's stack frame and passing a pointer
> > to the stack frame (i.e. arguments may not be at top of the stack).
> > We also noticed that sparc code does not save/restore anything from
> > the stack.
>
> I was reluctant to do that in the context of late changes to v4.8 for arm64
> but now that any changes for this are going in as a new patch it would
> indeed be useful to get involvement from sparc maintainers.
I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
Whether you can mention sparc64 as well, it depends on the sparc
maintainers. You can either cc them or send the series as two patches,
one for documentation and the other for arm64.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-09 17:23 ` Catalin Marinas
0 siblings, 0 replies; 147+ messages in thread
From: Catalin Marinas @ 2016-08-09 17:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
> >On 04/08/16 05:47, David Long wrote:
> >>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
> >>From: "David A. Long" <dave.long@linaro.org>
> >>Date: Thu, 4 Aug 2016 00:35:33 -0400
> >>Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
> >>
> >>Because the arm64 calling standard allows stacked function arguments
> >>to be
> >>anywhere in the stack frame, do not attempt to duplicate the stack
> >>frame for
> >>jprobes handler functions.
> >>
> >>Signed-off-by: David A. Long <dave.long@linaro.org>
> >>---
> >> Documentation/kprobes.txt | 7 +++++++
> >> arch/arm64/include/asm/kprobes.h | 2 --
> >> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
> >> 3 files changed, 12 insertions(+), 28 deletions(-)
> >>
> >>diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> >>index 1f9b3e2..bd01839 100644
> >>--- a/Documentation/kprobes.txt
> >>+++ b/Documentation/kprobes.txt
> >>@@ -103,6 +103,13 @@ Note that the probed function's args may be
> >>passed on the stack
> >> or in registers. The jprobe will work in either case, so long as the
> >> handler's prototype matches that of the probed function.
> >>
> >>+Note that in some architectures (e.g.: arm64) the stack copy is not
> >
> >Could sparc64 be added to this list?
> >
> > For the sparc folks who are new to the thread, we've previously
> > established that the sparc64 ABI passes large structures by
> > allocating them from the caller's stack frame and passing a pointer
> > to the stack frame (i.e. arguments may not be at top of the stack).
> > We also noticed that sparc code does not save/restore anything from
> > the stack.
>
> I was reluctant to do that in the context of late changes to v4.8 for arm64
> but now that any changes for this are going in as a new patch it would
> indeed be useful to get involvement from sparc maintainers.
I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
Whether you can mention sparc64 as well, it depends on the sparc
maintainers. You can either cc them or send the series as two patches,
one for documentation and the other for arm64.
--
Catalin
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
2016-08-09 17:23 ` Catalin Marinas
(?)
@ 2016-08-10 20:41 ` David Long
-1 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-10 20:41 UTC (permalink / raw)
To: Catalin Marinas
Cc: Daniel Thompson, Mark Rutland, Petr Mladek, Zi Shen Lim,
Will Deacon, sparclinux, Andrey Ryabinin, yalin wang, Li Bin,
Jisheng Zhang, John Blackwood, Pratyush Anand, Huang Shijie,
Dave P Martin, Yang Shi, Vladimir Murzin, Steve Capper,
Suzuki K Poulose, Marc Zyngier, Mark Brown, Sandeepa Prabhu,
William Cohen, Alex Bennée, Adam Buchbinder,
linux-arm-kernel, Ard Biesheuvel, linux-kernel, James Morse,
Masami Hiramatsu, Andrew Morton, Robin Murphy, Jens Wiklander,
Christoffer Dall
On 08/09/2016 01:23 PM, Catalin Marinas wrote:
> On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
>> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
>>> On 04/08/16 05:47, David Long wrote:
>>> >From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>>>> From: "David A. Long" <dave.long@linaro.org>
>>>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>>>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>>>
>>>> Because the arm64 calling standard allows stacked function arguments
>>>> to be
>>>> anywhere in the stack frame, do not attempt to duplicate the stack
>>>> frame for
>>>> jprobes handler functions.
>>>>
>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>> ---
>>>> Documentation/kprobes.txt | 7 +++++++
>>>> arch/arm64/include/asm/kprobes.h | 2 --
>>>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>>>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>>>
>>>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>>>> index 1f9b3e2..bd01839 100644
>>>> --- a/Documentation/kprobes.txt
>>>> +++ b/Documentation/kprobes.txt
>>>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>>>> passed on the stack
>>>> or in registers. The jprobe will work in either case, so long as the
>>>> handler's prototype matches that of the probed function.
>>>>
>>>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>>>
>>> Could sparc64 be added to this list?
>>>
>>> For the sparc folks who are new to the thread, we've previously
>>> established that the sparc64 ABI passes large structures by
>>> allocating them from the caller's stack frame and passing a pointer
>>> to the stack frame (i.e. arguments may not be at top of the stack).
>>> We also noticed that sparc code does not save/restore anything from
>>> the stack.
>>
>> I was reluctant to do that in the context of late changes to v4.8 for arm64
>> but now that any changes for this are going in as a new patch it would
>> indeed be useful to get involvement from sparc maintainers.
>
> I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
> Whether you can mention sparc64 as well, it depends on the sparc
> maintainers. You can either cc them or send the series as two patches,
> one for documentation and the other for arm64.
>
I didn't think that was going to be possible after v4.8-rc1. I have
separated the documentation and code changes. I will send out the new
code-only patch (otherwise unchanged in content) momentarily.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-10 20:41 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-10 20:41 UTC (permalink / raw)
To: linux-arm-kernel
On 08/09/2016 01:23 PM, Catalin Marinas wrote:
> On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
>> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
>>> On 04/08/16 05:47, David Long wrote:
>>> >From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>>>> From: "David A. Long" <dave.long@linaro.org>
>>>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>>>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>>>
>>>> Because the arm64 calling standard allows stacked function arguments
>>>> to be
>>>> anywhere in the stack frame, do not attempt to duplicate the stack
>>>> frame for
>>>> jprobes handler functions.
>>>>
>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>> ---
>>>> Documentation/kprobes.txt | 7 +++++++
>>>> arch/arm64/include/asm/kprobes.h | 2 --
>>>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>>>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>>>
>>>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>>>> index 1f9b3e2..bd01839 100644
>>>> --- a/Documentation/kprobes.txt
>>>> +++ b/Documentation/kprobes.txt
>>>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>>>> passed on the stack
>>>> or in registers. The jprobe will work in either case, so long as the
>>>> handler's prototype matches that of the probed function.
>>>>
>>>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>>>
>>> Could sparc64 be added to this list?
>>>
>>> For the sparc folks who are new to the thread, we've previously
>>> established that the sparc64 ABI passes large structures by
>>> allocating them from the caller's stack frame and passing a pointer
>>> to the stack frame (i.e. arguments may not be at top of the stack).
>>> We also noticed that sparc code does not save/restore anything from
>>> the stack.
>>
>> I was reluctant to do that in the context of late changes to v4.8 for arm64
>> but now that any changes for this are going in as a new patch it would
>> indeed be useful to get involvement from sparc maintainers.
>
> I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
> Whether you can mention sparc64 as well, it depends on the sparc
> maintainers. You can either cc them or send the series as two patches,
> one for documentation and the other for arm64.
>
I didn't think that was going to be possible after v4.8-rc1. I have
separated the documentation and code changes. I will send out the new
code-only patch (otherwise unchanged in content) momentarily.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v15 04/10] arm64: Kprobes with single stepping support
@ 2016-08-10 20:41 ` David Long
0 siblings, 0 replies; 147+ messages in thread
From: David Long @ 2016-08-10 20:41 UTC (permalink / raw)
To: linux-arm-kernel
On 08/09/2016 01:23 PM, Catalin Marinas wrote:
> On Mon, Aug 08, 2016 at 10:29:05AM -0400, David Long wrote:
>> On 08/08/2016 07:13 AM, Daniel Thompson wrote:
>>> On 04/08/16 05:47, David Long wrote:
>>> >From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
>>>> From: "David A. Long" <dave.long@linaro.org>
>>>> Date: Thu, 4 Aug 2016 00:35:33 -0400
>>>> Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
>>>>
>>>> Because the arm64 calling standard allows stacked function arguments
>>>> to be
>>>> anywhere in the stack frame, do not attempt to duplicate the stack
>>>> frame for
>>>> jprobes handler functions.
>>>>
>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>>> ---
>>>> Documentation/kprobes.txt | 7 +++++++
>>>> arch/arm64/include/asm/kprobes.h | 2 --
>>>> arch/arm64/kernel/probes/kprobes.c | 31 +++++--------------------------
>>>> 3 files changed, 12 insertions(+), 28 deletions(-)
>>>>
>>>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>>>> index 1f9b3e2..bd01839 100644
>>>> --- a/Documentation/kprobes.txt
>>>> +++ b/Documentation/kprobes.txt
>>>> @@ -103,6 +103,13 @@ Note that the probed function's args may be
>>>> passed on the stack
>>>> or in registers. The jprobe will work in either case, so long as the
>>>> handler's prototype matches that of the probed function.
>>>>
>>>> +Note that in some architectures (e.g.: arm64) the stack copy is not
>>>
>>> Could sparc64 be added to this list?
>>>
>>> For the sparc folks who are new to the thread, we've previously
>>> established that the sparc64 ABI passes large structures by
>>> allocating them from the caller's stack frame and passing a pointer
>>> to the stack frame (i.e. arguments may not be at top of the stack).
>>> We also noticed that sparc code does not save/restore anything from
>>> the stack.
>>
>> I was reluctant to do that in the context of late changes to v4.8 for arm64
>> but now that any changes for this are going in as a new patch it would
>> indeed be useful to get involvement from sparc maintainers.
>
> I'm happy to take the arm64 patch for 4.8 as it's mainly a clean-up.
> Whether you can mention sparc64 as well, it depends on the sparc
> maintainers. You can either cc them or send the series as two patches,
> one for documentation and the other for arm64.
>
I didn't think that was going to be possible after v4.8-rc1. I have
separated the documentation and code changes. I will send out the new
code-only patch (otherwise unchanged in content) momentarily.
Thanks,
-dl
^ permalink raw reply [flat|nested] 147+ messages in thread
end of thread, other threads:[~2016-08-10 20:49 UTC | newest]
Thread overview: 147+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-08 16:35 [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2016-07-08 16:35 ` David Long
2016-07-15 10:57 ` Catalin Marinas
2016-07-15 10:57 ` Catalin Marinas
2016-07-15 14:51 ` David Long
2016-07-15 14:51 ` David Long
2016-07-15 15:13 ` Catalin Marinas
2016-07-15 15:13 ` Catalin Marinas
2016-07-15 17:51 ` David Long
2016-07-15 17:51 ` David Long
2016-07-19 14:17 ` Catalin Marinas
2016-07-19 14:17 ` Catalin Marinas
2016-07-08 16:35 ` [PATCH v15 02/10] arm64: Add more test functions to insn.c David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 03/10] arm64: add conditional instruction simulation support David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 04/10] arm64: Kprobes with single stepping support David Long
2016-07-08 16:35 ` David Long
2016-07-20 9:36 ` Marc Zyngier
2016-07-20 9:36 ` Marc Zyngier
2016-07-20 11:16 ` Catalin Marinas
2016-07-20 11:16 ` Catalin Marinas
2016-07-20 19:08 ` David Long
2016-07-20 19:08 ` David Long
2016-07-21 8:44 ` Marc Zyngier
2016-07-21 8:44 ` Marc Zyngier
2016-07-20 15:49 ` Catalin Marinas
2016-07-20 15:49 ` Catalin Marinas
2016-07-21 14:50 ` David Long
2016-07-21 14:50 ` David Long
2016-07-20 16:09 ` Marc Zyngier
2016-07-20 16:09 ` Marc Zyngier
2016-07-20 16:28 ` Catalin Marinas
2016-07-20 16:28 ` Catalin Marinas
2016-07-20 16:31 ` Marc Zyngier
2016-07-20 16:31 ` Marc Zyngier
2016-07-20 16:46 ` Marc Zyngier
2016-07-20 16:46 ` Marc Zyngier
2016-07-20 17:04 ` Catalin Marinas
2016-07-20 17:04 ` Catalin Marinas
2016-07-21 16:33 ` David Long
2016-07-21 16:33 ` David Long
2016-07-21 17:16 ` Catalin Marinas
2016-07-21 17:16 ` Catalin Marinas
2016-07-21 17:23 ` Marc Zyngier
2016-07-21 17:23 ` Marc Zyngier
2016-07-21 18:33 ` David Long
2016-07-21 18:33 ` David Long
2016-07-22 10:16 ` Catalin Marinas
2016-07-22 10:16 ` Catalin Marinas
2016-07-22 15:51 ` David Long
2016-07-22 15:51 ` David Long
2016-07-25 17:13 ` Catalin Marinas
2016-07-25 17:13 ` Catalin Marinas
2016-07-25 22:27 ` David Long
2016-07-25 22:27 ` David Long
2016-07-27 11:50 ` Daniel Thompson
2016-07-27 11:50 ` Daniel Thompson
2016-07-27 22:13 ` David Long
2016-07-27 22:13 ` David Long
2016-07-28 14:40 ` Catalin Marinas
2016-07-28 14:40 ` Catalin Marinas
2016-07-29 9:01 ` Daniel Thompson
2016-07-29 9:01 ` Daniel Thompson
2016-08-04 4:47 ` David Long
2016-08-04 4:47 ` David Long
2016-08-08 11:13 ` Daniel Thompson
2016-08-08 11:13 ` Daniel Thompson
2016-08-08 11:13 ` Daniel Thompson
2016-08-08 14:29 ` David Long
2016-08-08 14:29 ` David Long
2016-08-08 14:29 ` David Long
2016-08-08 22:49 ` Masami Hiramatsu
2016-08-08 22:49 ` Masami Hiramatsu
2016-08-08 22:49 ` Masami Hiramatsu
2016-08-09 17:23 ` Catalin Marinas
2016-08-09 17:23 ` Catalin Marinas
2016-08-09 17:23 ` Catalin Marinas
2016-08-10 20:41 ` David Long
2016-08-10 20:41 ` David Long
2016-08-10 20:41 ` David Long
2016-08-08 22:19 ` Masami Hiramatsu
2016-08-08 22:19 ` Masami Hiramatsu
2016-07-26 9:50 ` Daniel Thompson
2016-07-26 9:50 ` Daniel Thompson
2016-07-26 16:55 ` Catalin Marinas
2016-07-26 16:55 ` Catalin Marinas
2016-07-27 10:01 ` Dave Martin
2016-07-27 10:01 ` Dave Martin
2016-07-26 17:54 ` Mark Rutland
2016-07-26 17:54 ` Mark Rutland
2016-07-27 11:19 ` Daniel Thompson
2016-07-27 11:19 ` Daniel Thompson
2016-07-27 11:38 ` Dave Martin
2016-07-27 11:38 ` Dave Martin
2016-07-27 11:42 ` Daniel Thompson
2016-07-27 11:42 ` Daniel Thompson
2016-07-27 13:38 ` Mark Rutland
2016-07-27 13:38 ` Mark Rutland
2016-07-08 16:35 ` [PATCH v15 05/10] arm64: Blacklist non-kprobe-able symbol David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able David Long
2016-07-08 16:35 ` David Long
2016-07-15 16:47 ` Catalin Marinas
2016-07-15 16:47 ` Catalin Marinas
2016-07-19 0:53 ` David Long
2016-07-19 0:53 ` David Long
2016-07-08 16:35 ` [PATCH v15 07/10] arm64: kprobes instruction simulation support David Long
2016-07-08 16:35 ` David Long
2016-07-10 22:51 ` Paul Gortmaker
2016-07-10 22:51 ` Paul Gortmaker
2016-07-08 16:35 ` [PATCH v15 08/10] arm64: Add trampoline code for kretprobes David Long
2016-07-08 16:35 ` David Long
2016-07-19 13:46 ` Catalin Marinas
2016-07-19 13:46 ` Catalin Marinas
2016-07-20 18:28 ` David Long
2016-07-20 18:28 ` David Long
2016-07-08 16:35 ` [PATCH v15 09/10] arm64: Add kernel return probes support (kretprobes) David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 10/10] kprobes: Add arm64 case in kprobe example module David Long
2016-07-08 16:35 ` David Long
2016-07-14 16:22 ` [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Catalin Marinas
2016-07-14 16:22 ` Catalin Marinas
2016-07-14 17:09 ` William Cohen
2016-07-14 17:09 ` William Cohen
2016-07-15 7:50 ` Catalin Marinas
2016-07-15 7:50 ` Catalin Marinas
2016-07-15 8:01 ` Marc Zyngier
2016-07-15 8:01 ` Marc Zyngier
2016-07-15 8:59 ` Alex Bennée
2016-07-15 8:59 ` Alex Bennée
2016-07-15 9:04 ` Marc Zyngier
2016-07-15 9:04 ` Marc Zyngier
2016-07-15 9:53 ` Marc Zyngier
2016-07-15 9:53 ` Marc Zyngier
2016-07-14 17:56 ` David Long
2016-07-14 17:56 ` David Long
2016-07-19 13:57 ` Catalin Marinas
2016-07-19 13:57 ` Catalin Marinas
2016-07-19 14:01 ` David Long
2016-07-19 14:01 ` David Long
2016-07-19 18:27 ` Catalin Marinas
2016-07-19 18:27 ` Catalin Marinas
2016-07-19 19:38 ` David Long
2016-07-19 19:38 ` David Long
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.