lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Oct 2014 12:59:52 +0200
From:	Heiko Carstens <>
To:	Ananth N Mavinakayanahalli <>,
	Anil S Keshavamurthy <>,
	"David S. Miller" <>,
	Masami Hiramatsu <>,
	Ingo Molnar <>
Cc:	Vojtech Pavlik <>, Jiri Kosina <>,
	Jiri Slaby <>,
	Steven Rostedt <>,
	Martin Schwidefsky <>,,
	Heiko Carstens <>
Subject: [PATCH v2 0/2] s390 vs. kprobes on ftrace

Changed patch 1/2 to incorporate feedback from Masami Hiramatsu, and
introduce a new helper function check_ftrace_location().
The requested ftracetest has been sent as an own patch set, since it
has no dependency to these patches.

We would like to implement an architecture specific variant of "kprobes
on ftrace" without using the current HAVE_KPROBES_ON_FTRACE infrastructure
which is currently only used by x86.

The rationale for these two patches is:
- we want to patch the first instruction of the mcount code block to
  reduce the overhead of the function tracer
- we'd like to keep the ftrace_caller function as simple as possible and
  not require it to generate a 100% valid pt_regs structure as required
  This allows us to not generate the psw mask field in the pt_regs
  structure on each function tracer enabled function, which otherwise would
  be very expensive. Besides that program check generated pt_regs contents
  are "more" accurate than program generated ones and don't require any
  And also we can keep the ftrace and kprobes backends quite separated.

In order to make this work a small common code change is necessary which
removes a check if kprobe is being placed on an ftrace location (see
first patch).

If possible, I'd like to have an ACK from at least one of the kprobes
maintainers for the first patch and bring it upstream via the s390 tree.


Heiko Carstens (2):
  s390/ftrace,kprobes: allow to patch first instruction

 arch/Kconfig                    |   8 +++
 arch/s390/Kconfig               |   1 +
 arch/s390/include/asm/ftrace.h  |  52 ++++++++++++++--
 arch/s390/include/asm/kprobes.h |   1 +
 arch/s390/include/asm/lowcore.h |   4 +-
 arch/s390/include/asm/pgtable.h |  12 ++++
 arch/s390/kernel/asm-offsets.c  |   1 -
 arch/s390/kernel/early.c        |   4 --
 arch/s390/kernel/ftrace.c       | 132 +++++++++++++++++++++++++---------------
 arch/s390/kernel/kprobes.c      |  87 ++++++++++++++++++--------
 arch/s390/kernel/mcount.S       |   1 +
 arch/s390/kernel/setup.c        |   2 -
 arch/s390/kernel/smp.c          |   1 -
 kernel/kprobes.c                |  36 ++++++-----
 scripts/recordmcount.c          |   2 +-
 scripts/         |   2 +-
 16 files changed, 239 insertions(+), 107 deletions(-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists