From: Steven Rostedt <rostedt@goodmis.org>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: mhiramat@kernel.org, linux-trace-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events
Date: Wed, 6 Oct 2021 13:44:28 -0400 [thread overview]
Message-ID: <20211006134428.1132ebe0@gandalf.local.home> (raw)
In-Reply-To: <20211006172723.GA2812@kbox>
On Wed, 6 Oct 2021 10:27:23 -0700
Beau Belgrave <beaub@linux.microsoft.com> wrote:
> On Wed, Oct 06, 2021 at 12:54:41PM -0400, Steven Rostedt wrote:
> > > Psuedo code example of typical usage:
> > > page_fd = open("user_events_mmap", O_RDWR);
> > > page_data = mmap(NULL, PAGE_SIZE, PROT_READ, MAP_SHARED, page_fd, 0);
> > >
> > > data_fd = open("user_events_data", O_RDWR);
> > > data_id = ioctl(data_fd, DIAG_IOCSREG, "test");
> > >
> > > if (page_data[data_id]) write(data_fd, &payload, sizeof(payload));
> >
> > What is the type of "page_data". I'd like to test it before accepting it.
> >
> > From playing around, I see that page_data is of type char *.
> Yes, it is char *. I'll make this clear in the next patch version
> description.
Thanks.
>
> > > +/* Bits 0-6 are for known probe types, Bit 7 is for unknown probes */
> > > +#define EVENT_BIT_FTRACE 0
> > > +#define EVENT_BIT_PERF 1
> > > +#define EVENT_BIT_OTHER 7
> > > +
> > > +#define EVENT_STATUS_FTRACE (1 << EVENT_BIT_FTRACE)
> > > +#define EVENT_STATUS_PERF (1 << EVENT_BIT_PERF)
> > > +#define EVENT_STATUS_OTHER (1 << EVENT_BIT_OTHER)
> ...
> > > +#define DIAG_IOC_MAGIC '*'
> > > +#define DIAG_IOCSREG _IOW(DIAG_IOC_MAGIC, 0, char*)
> > > +#define DIAG_IOCSDEL _IOW(DIAG_IOC_MAGIC, 1, char*)
> > > +#define DIAG_IOCQLOCOFFSET _IO(DIAG_IOC_MAGIC, 2)
> >
> > These obviously will need to go into a user abi header file.
> >
> Yes, I'm glad you mentioned it. I wasn't entirely sure where it should
> live. Is there precedent on where to put these so they span both kernel
> and user for discovery / distribution?
There is a include/uapi directory in the Linux source code. I've never
added to it (that I remember, but maybe I have? Wouldn't surprise me if I
did and forgot about it :-p Sucks getting old).
>
> > > +
> > > +static char *register_page_data;
> > > +
> > > +static DEFINE_HASHTABLE(register_table, 4);
> > > +static DECLARE_BITMAP(page_bitmap, MAX_EVENTS);
> > > +
> > > +struct user_event {
> > > + struct tracepoint tracepoint;
> > > + struct trace_event_call call;
> > > + struct trace_event_class class;
> > > + struct dyn_event devent;
> > > + struct hlist_node node;
> > > + atomic_t refs;
> > > + int index;
> > > + char *args;
> > > +};
> > > +
> > > +#ifdef CONFIG_PERF_EVENTS
> > > +struct user_bpf_context {
> > > + int udatalen;
> > > + const char __user *udata;
> > > +};
> > > +#endif
> > > +
> > > +typedef void (*user_event_func_t) (struct user_event *user,
> > > + const char __user *udata,
> > > + size_t udatalen, void *tpdata);
> > > +
> > > +static int register_user_event(char *name, char *args,
> > > + struct user_event **newuser);
> > > +
> >
> > [..]
> >
> Is the ask here to get user_bpf_context definition also into a user ABI
> header? (I took it as that).
Not sure I understand the question.
>
> > > +static int __init trace_events_user_init(void)
> > > +{
> > > + int ret;
> > > +
> > > + /* Zero all bits beside 0 (which is reserved for failures) */
> > > + bitmap_zero(page_bitmap, MAX_EVENTS);
> > > + set_bit(0, page_bitmap);
> > > +
> > > + register_page_data = kmalloc(MAX_EVENTS, GFP_KERNEL);
> >
> > You want "kzalloc" here. Because when I read the map without adding
> > anything, I get:
> >
> > printf("%lx\n", *(unsigned long *)page_data);
> >
> > Produces:
> >
> > ffffffff9065004e
> >
> > But if I convert it to kzalloc() it gives me:
> >
> > 0
> >
> > Thus, you are exposing stale memory. If you want to expose this to
> > non-admin users, this is a major security leak.
> >
> > -- Steve
> >
> Oops, sorry about that!
No problem. Just pointing it out.
I expect that this is going to take a few back and forth to get right. But
I do like the way it is heading.
-- Steve
next prev parent reply other threads:[~2021-10-06 17:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 22:44 [PATCH] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-10-06 16:28 ` Masami Hiramatsu
2021-10-06 17:56 ` Beau Belgrave
2021-10-07 14:17 ` Masami Hiramatsu
2021-10-07 16:22 ` Beau Belgrave
2021-10-07 23:12 ` Masami Hiramatsu
2021-10-08 0:05 ` Beau Belgrave
2021-10-08 9:22 ` Masami Hiramatsu
2021-10-11 16:25 ` Beau Belgrave
2021-10-13 1:18 ` Steven Rostedt
2021-10-13 16:50 ` Beau Belgrave
2021-10-13 17:11 ` Steven Rostedt
2021-10-13 17:17 ` Beau Belgrave
2021-10-13 17:27 ` Steven Rostedt
2021-10-13 15:21 ` Masami Hiramatsu
2021-10-13 15:40 ` Steven Rostedt
2021-10-14 12:21 ` Masami Hiramatsu
2021-10-13 16:56 ` Beau Belgrave
2021-10-06 16:54 ` Steven Rostedt
2021-10-06 17:27 ` Beau Belgrave
2021-10-06 17:44 ` Steven Rostedt [this message]
2021-10-08 13:11 ` Peter.Enderborg
2021-10-08 16:09 ` Beau Belgrave
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=20211006134428.1132ebe0@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mhiramat@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 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).