[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251222121547.39b35b0d@gandalf.local.home>
Date: Mon, 22 Dec 2025 12:15:47 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: liujing40 <liujing.root@...il.com>
Cc: menglong.dong@...ux.dev, andrii@...nel.org, ast@...nel.org,
bpf@...r.kernel.org, daniel@...earbox.net, eddyz87@...il.com,
haoluo@...gle.com, john.fastabend@...il.com, jolsa@...nel.org,
kpsingh@...nel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, liujing40@...omi.com,
martin.lau@...ux.dev, mhiramat@...nel.org, sdf@...ichev.me,
song@...nel.org, yonghong.song@...ux.dev
Subject: Re: [PATCH 2/2] bpf: Implement kretprobe fallback for kprobe multi
link
On Mon, 22 Dec 2025 16:02:53 +0800
liujing40 <liujing.root@...il.com> wrote:
> The Dynamic ftrace feature is not enabled in Android for security reasons,
> forcing us to fall back on kretprobe.
Really? I would say kretprobe is a much bigger security risk than ftrace.
Ftrace only attaches to a set of defined functions and anything that is
enabled is displayed in /sys/kernel/tracing/enabled_functions (for security
reasons!)
Whereas kretprobe can attach to anything, and call anything. Not to
mention, there's no way to know if a kretprobe is there or not. So rootkits
that would use this can most definitely go under the wire, whereas they
can't with ftrace.
So if they disable ftrace for security reasons, they most definitely should
be disabling kprobes!
-- Steve
> https://source.android.com/docs/core/tests/debug/ftrace#dftrace
>
> I will provide the benchmark test results as soon as possible.
Powered by blists - more mailing lists