All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: kylebot@openai.com
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	rostedt@goodmis.org, mhiramat@kernel.org,
	outbounddisclosures@openai.com, Kyle Zeng <kylebot@openai.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] tracing/filters: Check perf permissions before accessing kernel data
Date: Wed, 07 Oct 2026 08:01:53 +0000	[thread overview]
Message-ID: <20261007080155.F2A0C1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261007050315.65139-1-kylebot@openai.com>

On Tue, 06 Oct 2026 22:03:15 -0700, Kyle Zeng <kylebot@openai.com> wrote:
> perf_trace_event_perm() allows tracepoint counters that do not request
> PERF_SAMPLE_RAW without raw tracepoint permissions. A self-targeted
> event with exclude_kernel=1 can therefore reach the filter compiler even
> at perf_event_paranoid=2.
>
> The .function suffix resolves its operand through kallsyms. The result
> of a numeric filter discloses whether an address belongs to a known
> kernel symbol range, allowing the randomized kernel image base to be
> recovered. A named filter also exposes the resolved range through the
> counter when the tracepoint field is controlled by the caller.
>
> Pointer-string filters expose kernel memory in the same way. A caller
> can supply a kernel address as the filename argument to openat() and
> install a string filter on sys_enter_openat. Without .ustring, the
> filter uses strncpy_from_kernel_nofault() on that address. Whether the
> counter increments reveals whether the kernel bytes match the pattern.
> The nofault copy prevents faults but does not authorize disclosure.
>
> Pass the filter's perf origin to the predicate parser and require
> perf_allow_tracepoint() before resolving a .function operand or creating
> a kernel-pointer string predicate. This uses the existing sysctl,
> initial-namespace capability and LSM policy for raw tracepoint access.
> Keep ordinary counting filters, explicit user-string predicates and
> filters created through the separately controlled tracefs interfaces
> unchanged.
>
> Fixes: e6745a4da964 ("tracing: Add a way to filter function addresses to function names")
> Fixes: 5967bd5c4239 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Kyle Zeng <kylebot@openai.com>

Looks good to me.

Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>

Thanks!

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

      reply	other threads:[~2026-10-07  8:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07  5:03 [PATCH v2] tracing/filters: Check perf permissions before accessing kernel data Kyle Zeng
2026-10-07  8:01 ` Masami Hiramatsu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261007080155.F2A0C1F0089B@smtp.kernel.org \
    --to=mhiramat@kernel.org \
    --cc=kylebot@openai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=outbounddisclosures@openai.com \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.