linux-kernel - Re: [PATCH] arm64/kprobes: Add support for KPROBES_ON

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221107144931.GA20793@willie-the-truck>
Date:   Mon, 7 Nov 2022 14:49:31 +0000
From:   Will Deacon <will@...nel.org>
To:     Jianlin Lv <iecedge@...il.com>
Cc:     corbet@....net, catalin.marinas@....com, rostedt@...dmis.org,
        mingo@...hat.com, naveen.n.rao@...ux.ibm.com,
        anil.s.keshavamurthy@...el.com, davem@...emloft.net,
        mhiramat@...nel.org, arnd@...db.de, zhengzengkai@...wei.com,
        jianlv@...y.com, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        mark.rutland@....com
Subject: Re: [PATCH] arm64/kprobes: Add support for KPROBES_ON_FTRACE

[+Mark R]

On Thu, Jul 28, 2022 at 02:02:50AM +0000, Jianlin Lv wrote:
> This is the arm64 version of ftrace-based kprobes to avoid the overhead
> with regular kprobes, by using the ftrace infrastructure.
> 
> Signed-off-by: Jianlin Lv <iecedge@...il.com>
> ---
>  .../debug/kprobes-on-ftrace/arch-support.txt  |  2 +-
>  arch/arm64/Kconfig                            |  1 +
>  arch/arm64/kernel/probes/Makefile             |  1 +
>  arch/arm64/kernel/probes/kprobes-ftrace.c     | 81 +++++++++++++++++++
>  include/linux/kprobes.h                       |  2 +
>  kernel/kprobes.c                              |  4 +-
>  6 files changed, 88 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm64/kernel/probes/kprobes-ftrace.c

Sorry for the slow reply on this, but I think this deserved to be split
into two patches: the first one reworking the core check_ftrace_location()
logic to work properly with branch-and-link style architectures, and the
second one adding support for arm64.

I'd also prefer that we don't just punt the whole of check_ftrace_location()
to the arch code using weak symbols. I'd have thought it would be cleaner
for architectures to specify the offset which needs to be applied to the
PC instead.

Having said that, how do architectures such as PowerPC and Risc-V handle
this today without changing the core code?

Will