From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, oss-drivers@netronome.com,
Jesper Dangaard Brouer <brouer@redhat.com>,
Stanislav Fomichev <sdf@google.com>
Subject: Re: Debugging eBPF was: Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device
Date: Fri, 14 Dec 2018 10:39:27 -0300 [thread overview]
Message-ID: <20181214133927.GP21027@kernel.org> (raw)
In-Reply-To: <20181213205508.u6izf4ugnpincyps@ast-mbp.dhcp.thefacebook.com>
Em Thu, Dec 13, 2018 at 12:55:10PM -0800, Alexei Starovoitov escreveu:
> On Thu, Dec 13, 2018 at 10:49:09AM -0300, Arnaldo Carvalho de Melo wrote:
> > Only root can attach eBPF programs to tracepoints.
> > Would be really good if we could have a more restricted program type to
> > attach to tracepoints, one that would be able to run only in the context
> > of their threads and access only the pointers in the tracepoints, that
> > way the 'perf trace' augmented syscalls code would be usable for
> > non-root users just like the other 'perf' commands are, allowing us to,
> > as with root, to copy the pointer arguments, like:
> I don't think there is a clean way of doing non-root with tracepoints or syscalls.
> The kernel side would need to start filtering the progs.
> Like current uid == uid of loaded prog. But then there are tail_calls.
Yeah, that program would run only for threads owned by the prog owner.
> they would need to be disabled.
I think if that is not possible, then would be an acceptable limitation
in a first implementation. I.e. my understanding is that eBPF started
with some limited scope, then as it goes maturing, more features were
added as its security/performance implications were understood.
> tracepoints args can be pointers. _all_ of them in the kernel would need to
> be annotated to make sure pointers don't leak into unpriv user space.
> and so on and so forth.
Yes, I thought about heavily restricting them, i.e. points would be
allowed just for some very special cases, like the arguments to
raw_syscalls.sys_{sys_enter,sys_exit}, as a starting point.
> I think better way forward would be to introduce something in the middle.
> Between root and unpriv. Something that tracing bpf progs can use.
> May be new capability?
Well, that would be interesting too, I think, would make go a bit
forward, for a class of applications where trusting the tracer is
possible.
- Arnaldo
next prev parent reply other threads:[~2018-12-14 13:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 12:19 [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 1/8] tools: bpftool: add basic probe capability, probe syscall and kversion Quentin Monnet
2018-12-14 2:50 ` Stanislav Fomichev
2018-12-14 11:27 ` Quentin Monnet
2018-12-14 18:45 ` Stanislav Fomichev
2018-12-15 3:31 ` Quentin Monnet
2018-12-14 23:35 ` Daniel Borkmann
2018-12-15 3:31 ` Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 2/8] tools: bpftool: add probes for /proc/ eBPF parameters Quentin Monnet
2018-12-14 2:58 ` Stanislav Fomichev
2018-12-14 11:27 ` Quentin Monnet
2018-12-14 23:40 ` Daniel Borkmann
2018-12-15 3:31 ` Quentin Monnet
2018-12-16 0:14 ` Daniel Borkmann
2018-12-17 10:44 ` Quentin Monnet
2018-12-17 11:11 ` Daniel Borkmann
2018-12-13 12:19 ` [PATCH bpf-next 3/8] tools: bpftool: add probes for kernel configuration options Quentin Monnet
2018-12-14 23:56 ` Daniel Borkmann
2018-12-15 3:32 ` Quentin Monnet
2018-12-19 18:49 ` Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 4/8] tools: bpftool: add probes for eBPF program types Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 5/8] tools: bpftool: add probes for eBPF map types Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 6/8] tools: bpftool: add probes for eBPF helper functions Quentin Monnet
2018-12-15 0:08 ` Daniel Borkmann
2018-12-15 3:32 ` Quentin Monnet
2018-12-15 23:57 ` Daniel Borkmann
2018-12-17 10:18 ` Quentin Monnet
2018-12-18 0:42 ` Daniel Borkmann
2018-12-19 19:02 ` Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 7/8] tools: bpftool: add probes for a network device Quentin Monnet
2018-12-13 12:19 ` [PATCH bpf-next 8/8] tools: bpftool: add bash completion for bpftool probes Quentin Monnet
2018-12-13 13:03 ` [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device Arnaldo Carvalho de Melo
2018-12-13 13:49 ` Debugging eBPF was: " Arnaldo Carvalho de Melo
2018-12-13 20:55 ` Alexei Starovoitov
2018-12-14 13:39 ` Arnaldo Carvalho de Melo [this message]
2018-12-14 11:53 ` Quentin Monnet
2018-12-14 18:21 ` Stanislav Fomichev
2018-12-14 18:41 ` [oss-drivers] " Quentin Monnet
2018-12-14 14:00 ` Arnaldo Carvalho de Melo
2018-12-14 14:56 ` Quentin Monnet
2018-12-14 17:26 ` Arnaldo Carvalho de Melo
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=20181214133927.GP21027@kernel.org \
--to=acme@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=quentin.monnet@netronome.com \
--cc=sdf@google.com \
/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).