mbox series

[v3,0/4] arm64: kprobes: Update blacklist checking on arm64

Message ID 154998617300.21869.11457765723750331236.stgit@devbox (mailing list archive)
Headers show
Series arm64: kprobes: Update blacklist checking on arm64 | expand

Message

Masami Hiramatsu (Google) Feb. 12, 2019, 3:42 p.m. UTC
Hello,

Here is the v3 series of update of the kprobe blacklist
checking on arm64.

I found that some blacklist checking code were mis-placed in
arch_prepare_kprobe() and arch_within_kprobe_blacklist().
Since the blacklist just filters by symbol, smaller than the
symbol, like extable must be checked in arch_prepare_kprobe().
Also, all function (symbol) level check must be done by blacklist.

For arm64, it checks the extable entry address in blacklist
and exception/irqentry function in arch_prepare_kprobe().
And, RODATA check is unneeded since kernel/kprobes.c
already ensures the probe address is in kernel-text area.

In v3, I rebased on the latest arm64 kernel which includes
James' KVM/HYP fixes for kprobes, and fix a reported bugs
in [4/4].

Changes in v3:
 - [4/4] Fixes to remove redundant blacklist of kprobe_text
   and add blacklist on exception_text.

Thank you,

---

Masami Hiramatsu (4):
      arm64: kprobes: Move extable address check into arch_prepare_kprobe()
      arm64: kprobes: Remove unneeded RODATA check
      arm64: kprobes: Move exception_text check in blacklist
      arm64: kprobes: Use arch_populate_kprobe_blacklist()


 arch/arm64/kernel/probes/kprobes.c |   52 +++++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 25 deletions(-)

--
Masami Hiramatsu (Linaro) <mhiramat@kernel.org>

Comments

Catalin Marinas Feb. 15, 2019, 5:46 p.m. UTC | #1
Hi Masami,

On Wed, Feb 13, 2019 at 12:42:53AM +0900, Masami Hiramatsu wrote:
> In v3, I rebased on the latest arm64 kernel which includes
> James' KVM/HYP fixes for kprobes, and fix a reported bugs
> in [4/4].

I will queue this patches at 5.1-rc1 since the arm64 for-next/core
branch is currently based on -rc3 and does not include James' fix. Even
if I rebased your patches on top of -rc3, we'd still get a conflict when
pushing into mainline, so I'd rather send them after -rc1.

Thanks.