netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).