[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181213205508.u6izf4ugnpincyps@ast-mbp.dhcp.thefacebook.com>
Date: Thu, 13 Dec 2018 12:55:10 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Quentin Monnet <quentin.monnet@...ronome.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
oss-drivers@...ronome.com,
Jesper Dangaard Brouer <brouer@...hat.com>,
Stanislav Fomichev <sdf@...gle.com>
Subject: Re: Debugging eBPF was: Re: [PATCH bpf-next 0/8] tools: bpftool: add
probes for system and device
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.
they would need to be disabled.
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.
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?
Powered by blists - more mailing lists