From: Steven Rostedt <email@example.com>
To: Pingfan Liu <firstname.lastname@example.org>
Cc: David Laight <David.Laight@aculab.com>,
Ingo Molnar <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Masami Hiramatsu <email@example.com>,
Tom Zanussi <firstname.lastname@example.org>
Subject: Re: [PATCH v2] tracing: Add test for user space strings when filtering on string pointers
Date: Thu, 13 Jan 2022 13:04:04 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
On Wed, 12 Jan 2022 12:13:03 +0800
Pingfan Liu <firstname.lastname@example.org> wrote:
> Hi Steven,
> Sorry that I am out of office, and not reply in time.
And I've been very sick for the last few days :-p
> On Mon, Jan 10, 2022 at 12:24:36PM -0500, Steven Rostedt wrote:
> > On Mon, 10 Jan 2022 17:11:52 +0000
> > David Laight <David.Laight@ACULAB.COM> wrote:
> > > From: Steven Rostedt
> > > > Sent: 10 January 2022 16:56
> > > >
> > > > From: Steven Rostedt <email@example.com>
> > > >
> > > > Pingfan reported that the following causes a fault:
> > > >
> > > > echo "filename ~ \"cpu\"" > events/syscalls/sys_enter_openat/filter
> > > > echo 1 > events/syscalls/sys_enter_at/enable
> > > >
> > > > The reason is that trace event filter treats the user space pointer
> > > > defined by "filename" as a normal pointer to compare against the "cpu"
> > > > string. If the string is not loaded into memory yet, it will trigger a
> > > > fault in kernel space:
> For accurate commit log, the swapped-out user page is not the root cause
> of this bug is "supervisor read access in kernel mode". And it is trueth
> that swapped-out user page can trigger a bug here, but it should be a
> different a stack.
Yeah, it's true that the bug that triggered is the supervisor access, but
that's more of a security concern (and an option that triggers this, to
find bugs of this kind :-) To me, the real bug is the random read of a
pointer. I can update the change log to be a bit more specific.
> > >
> > > If a userspace pointer can end up the kernel structure then presumably
> > > a 'dodgy' user program can supply an arbitrary kernel address instead?
> > > This may give the user the ability to read arbitrary kernel addresses
> > > (including ones that are mapped to PCIe IO addresses).
> > > Doesn't sound good at all.
> > Only root has access to the information read here. All tracing requires
> > root or those explicitly given access to the tracing data, which pretty
> > much allows all access to kernel internals (including all memory). So
> > nothing to worry about here ;-)
> I am not sure about the opposite way. Since kernel is not allowed to
> access userspace most of the time, then is it an leakage, which looks
> use tracepoint as trampoline to uaccess.
> read out user info from ustring_per_cpu
> But any kernel code can call copy_from_user() function family freely, so
> it is not a problem caused by this patch, right? Or ustring_per_cpu
> should be zeroed out.
And you can use tracing to create a kprobe that can read user space at
almost any place in the kernel. Hence, we have API that allows root to do
this, which is why I'm not concerned about it.
> For V2, feel free to add "Tested-by"
next prev parent reply other threads:[~2022-01-13 18:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 16:55 [PATCH v2] tracing: Add test for user space strings when filtering on string pointers Steven Rostedt
2022-01-10 17:11 ` David Laight
2022-01-10 17:24 ` Steven Rostedt
2022-01-10 17:29 ` Steven Rostedt
2022-01-10 21:58 ` David Laight
2022-01-11 20:55 ` Sven Schnelle
2022-01-13 17:57 ` Steven Rostedt
2022-01-13 21:28 ` Sven Schnelle
2022-01-13 21:51 ` Steven Rostedt
2022-01-14 2:15 ` Steven Rostedt
2022-01-14 7:29 ` Sven Schnelle
2022-01-14 9:35 ` David Laight
2022-01-13 22:11 ` David Laight
2022-01-13 22:28 ` Steven Rostedt
2022-01-10 22:03 ` David Laight
2022-01-11 0:21 ` Steven Rostedt
2022-01-12 4:13 ` Pingfan Liu
2022-01-13 18:04 ` Steven Rostedt [this message]
2022-01-13 22:02 ` Steven Rostedt
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.