From: Beau Belgrave <beaub@linux.microsoft.com>
To: rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com, dcook@linux.microsoft.com,
alanau@linux.microsoft.com
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: [PATCH 0/3] tracing/user_events: Fixes and improvements for 6.4
Date: Tue, 11 Apr 2023 14:17:06 -0700 [thread overview]
Message-ID: <20230411211709.15018-1-beaub@linux.microsoft.com> (raw)
Now that user_events is in for-next we broadened our integration of
user_events. During this integration we found a few things that can
help prevent the debugging of issues for user_events when user
processes use the ABI directly.
The most important thing found is an out of bounds fix with the
write index. If it is negative, an out of bounds access is attempted.
This bug was introduced on one of the very first user_events patches
and remained unseen for a long time. Apologies for not catching that
sooner.
We think users will expect the kernel to always clear the registered
bit when events are unregistered, even if the event is still enabled
in a kernel tracer. The user process could do this after unregistering,
but it seems appropriate for the kernel side to attempt this. We also
discussed if it makes sense for the kernel to allow user processes
to tie multiple events to the same value and bit. While this doesn't
cause any issues on the kernel side, it leads to very undefined
behavior for the user process. Depending on which event gets enabled
when, the bit will vary.
Beau Belgrave (3):
tracing/user_events: Ensure write index cannot be negative
tracing/user_events: Ensure bit is cleared on unregister
tracing/user_events: Prevent same address and bit per process
kernel/trace/trace_events_user.c | 77 +++++++++++++++++++
.../testing/selftests/user_events/abi_test.c | 9 ++-
.../selftests/user_events/ftrace_test.c | 14 +++-
3 files changed, 96 insertions(+), 4 deletions(-)
base-commit: 88fe1ec75fcb296579e05eaf3807da3ee83137e4
--
2.25.1
next reply other threads:[~2023-04-11 21:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 21:17 Beau Belgrave [this message]
2023-04-11 21:17 ` [PATCH 1/3] tracing/user_events: Ensure write index cannot be negative Beau Belgrave
2023-04-25 14:43 ` Masami Hiramatsu
2023-04-11 21:17 ` [PATCH 2/3] tracing/user_events: Ensure bit is cleared on unregister Beau Belgrave
2023-04-25 1:39 ` Steven Rostedt
2023-04-25 17:06 ` Beau Belgrave
2023-04-25 17:56 ` Steven Rostedt
2023-04-11 21:17 ` [PATCH 3/3] tracing/user_events: Prevent same address and bit per process Beau Belgrave
2023-04-25 1:41 ` Steven Rostedt
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=20230411211709.15018-1-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=alanau@linux.microsoft.com \
--cc=dcook@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).