On 10/3/19 9:41 AM, Steven Rostedt wrote:
> On Thu, 3 Oct 2019 09:18:40 -0700
> Alexei Starovoitov wrote:
>
>> I think dropping last events is just as bad. Is there a mode to overwrite old
>> and keep the last N (like perf does) ?
>
> Well, it drops it by pages. Thus you should always have the l
On Thu, Oct 03, 2019 at 03:12:04PM +0900, Masami Hiramatsu wrote:
> On Mon, 30 Sep 2019 11:31:29 -0700
> Kees Cook wrote:
>
> > On Sat, Sep 28, 2019 at 07:37:27PM -0400, Steven Rostedt wrote:
> > > On Wed, 28 Aug 2019 21:07:24 -0700
> > > Alexei Starovoitov wrote:
> > > > >
> > > > > This won’t
On Thu, 3 Oct 2019 09:18:40 -0700
Alexei Starovoitov wrote:
> I think dropping last events is just as bad. Is there a mode to overwrite old
> and keep the last N (like perf does) ?
Well, it drops it by pages. Thus you should always have the last page
of events.
> Peter Wu brought this issue to
On Wed, Oct 02, 2019 at 07:00:27PM -0400, Steven Rostedt wrote:
> >
> > Both 'trace' and 'trace_pipe' have quirky side effects.
> > Like opening 'trace' file will make all parallel trace_printk() to be
> > ignored.
> > While reading 'trace_pipe' file will clear it.
> > >>>
On Mon, 30 Sep 2019 11:31:29 -0700
Kees Cook wrote:
> On Sat, Sep 28, 2019 at 07:37:27PM -0400, Steven Rostedt wrote:
> > On Wed, 28 Aug 2019 21:07:24 -0700
> > Alexei Starovoitov wrote:
> > > >
> > > > This won’t make me much more comfortable, since CAP_BPF lets it do an
> > > > ever-growing
On Wed, 2 Oct 2019 17:18:21 +
Alexei Starovoitov wrote:
> >> It's an interesting idea, but I don't think it can work.
> >> Please see bpf_trace_printk implementation in kernel/trace/bpf_trace.c
> >> It's a lot more than string printing.
> >
> > Well, trace_printk() is just string printing.
On 10/1/19 3:47 PM, Steven Rostedt wrote:
> On Tue, 1 Oct 2019 22:18:18 +
> Alexei Starovoitov wrote:
>
>>> And then you can just format the string from the bpf_trace_printk()
>>> into msg, and then have:
>>>
>>> trace_bpf_print(msg);
>>
>> It's an interesting idea, but I don't think it c
On Tue, 1 Oct 2019 22:18:18 +
Alexei Starovoitov wrote:
> > And then you can just format the string from the bpf_trace_printk()
> > into msg, and then have:
> >
> > trace_bpf_print(msg);
>
> It's an interesting idea, but I don't think it can work.
> Please see bpf_trace_printk impleme
On 10/1/19 3:10 PM, Steven Rostedt wrote:
> On Mon, 30 Sep 2019 18:22:28 -0700
> Alexei Starovoitov wrote:
>
>> tracefs is a file system, so clearly file based acls are much better fit
>> for all tracefs operations.
>> But that is not the case for ftrace overall.
>> bpf_trace_printk() calls trace
On Mon, 30 Sep 2019 18:22:28 -0700
Alexei Starovoitov wrote:
> tracefs is a file system, so clearly file based acls are much better fit
> for all tracefs operations.
> But that is not the case for ftrace overall.
> bpf_trace_printk() calls trace_printk() that dumps into trace pipe.
> Technically
On Mon, Sep 30, 2019 at 11:31:29AM -0700, Kees Cook wrote:
> On Sat, Sep 28, 2019 at 07:37:27PM -0400, Steven Rostedt wrote:
> > On Wed, 28 Aug 2019 21:07:24 -0700
> > Alexei Starovoitov wrote:
> > > >
> > > > This won’t make me much more comfortable, since CAP_BPF lets it do an
> > > > ever-gro
On Sat, Sep 28, 2019 at 07:37:27PM -0400, Steven Rostedt wrote:
> On Wed, 28 Aug 2019 21:07:24 -0700
> Alexei Starovoitov wrote:
> > >
> > > This won’t make me much more comfortable, since CAP_BPF lets it do an
> > > ever-growing set of nasty things. I’d much rather one or both of two
> > > thi
On Wed, 28 Aug 2019 21:07:24 -0700
Alexei Starovoitov wrote:
> >
> > This won’t make me much more comfortable, since CAP_BPF lets it do an
> > ever-growing set of nasty things. I’d much rather one or both of two things
> > happen:
> >
> > 1. Give it CAP_TRACING only. It can leak my data, but i
On Thu, 29 Aug 2019 10:23:10 -0700
Alexei Starovoitov wrote:
> > CAP_TRACE_KERNEL: Use all of perf, ftrace, kprobe, etc.
> >
> > CAP_TRACE_USER: Use all of perf with scope limited to user mode and
> > uprobes.
>
> imo that makes little sense from security pov, since
> such CAP_TRACE_KERNEL (
On Thu, 29 Aug 2019 10:19:24 -0700
Alexei Starovoitov wrote:
> On Thu, Aug 29, 2019 at 09:34:34AM -0400, Steven Rostedt wrote:
> >
> > As the above seems to favor the idea of CAP_TRACING allowing write
> > access to tracefs, should we have a CAP_TRACING_RO for just read access
> > and limited pe
On Thu, Aug 29, 2019 at 10:23 AM Alexei Starovoitov
wrote:
>
> On Thu, Aug 29, 2019 at 08:43:23AM -0700, Andy Lutomirski wrote:
> >
> > I can imagine splitting it into three capabilities:
> >
> > CAP_TRACE_KERNEL: learn which kernel functions are called when. This
> > would allow perf profiling,
On Thu, Aug 29, 2019 at 08:43:23AM -0700, Andy Lutomirski wrote:
>
> I can imagine splitting it into three capabilities:
>
> CAP_TRACE_KERNEL: learn which kernel functions are called when. This
> would allow perf profiling, for example, but not sampling of kernel
> regs.
>
> CAP_TRACE_READ_KERN
On Thu, Aug 29, 2019 at 09:34:34AM -0400, Steven Rostedt wrote:
>
> As the above seems to favor the idea of CAP_TRACING allowing write
> access to tracefs, should we have a CAP_TRACING_RO for just read access
> and limited perf abilities?
read only vs writeable is an attribute of the file system.
On Thu, Aug 29, 2019 at 6:34 AM Steven Rostedt wrote:
>
> On Wed, 28 Aug 2019 15:08:28 -0700
> Alexei Starovoitov wrote:
>
> > On Wed, Aug 28, 2019 at 09:14:21AM +0200, Peter Zijlstra wrote:
> > > On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> > >
> > > > > Tracing:
> > > > >
On Wed, 28 Aug 2019 15:08:28 -0700
Alexei Starovoitov wrote:
> On Wed, Aug 28, 2019 at 09:14:21AM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> >
> > > > Tracing:
> > > >
> > > > CAP_BPF and perf_paranoid_tracepoint_raw() (which is
> > > >
On Wed, Aug 28, 2019 at 05:45:47PM -0700, Andy Lutomirski wrote:
> >
> >> It seems like you are specifically trying to add a new switch to turn
> >> as much of BPF as possible on and off. Why?
> >
> > Didn't I explain it several times already with multiple examples
> > from systemd, daemons, bpf
> On Aug 28, 2019, at 4:38 PM, Alexei Starovoitov
> wrote:
>
>> On Tue, Aug 27, 2019 at 11:20:19PM -0700, Andy Lutomirski wrote:
>> On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov
>> wrote:
>>>
On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote:
Let me put th
> On Aug 28, 2019, at 5:45 PM, Andy Lutomirski wrote:
>
>
>>> On Aug 28, 2019, at 3:55 PM, Alexei Starovoitov
>>> wrote:
>>>
>>> On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote:
>
>
> From the previous discussion, you want to make progress toward solving
>
> On Aug 28, 2019, at 3:55 PM, Alexei Starovoitov
> wrote:
>
>> On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote:
From the previous discussion, you want to make progress toward solving
a lot of problems with CAP_BPF. One of them was making BPF
firewal
On Tue, Aug 27, 2019 at 11:20:19PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote:
> > >
> > > Let me put this a bit differently. Part of the point is that
> > > CAP_TRACING should
On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote:
> >
> > >
> > > From the previous discussion, you want to make progress toward solving
> > > a lot of problems with CAP_BPF. One of them was making BPF
> > > firewalling more generally useful. By making CAP_BPF grant the ability
> >
On Wed, Aug 28, 2019 at 09:14:21AM +0200, Peter Zijlstra wrote:
> On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
>
> > > Tracing:
> > >
> > > CAP_BPF and perf_paranoid_tracepoint_raw() (which is
> > > kernel.perf_event_paranoid == -1)
> > > are necessary to:
>
> That's not trac
Hi Alexei,
I love your patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Alexei-Starovoitov/bpf-capabilities-introduce-CAP_BPF/20190828-142441
base:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-nex
On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> > Tracing:
> >
> > CAP_BPF and perf_paranoid_tracepoint_raw() (which is
> > kernel.perf_event_paranoid == -1)
> > are necessary to:
That's not tracing, that's perf.
> > +bool cap_bpf_tracing(void)
> > +{
> > + return capab
On Tue, Aug 27, 2019 at 9:49 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote:
> >
> > Let me put this a bit differently. Part of the point is that
> > CAP_TRACING should allow a user or program to trace without being able
> > to corrupt the system.
On Tue, Aug 27, 2019 at 9:43 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 05:55:41PM -0700, Andy Lutomirski wrote:
> >
> > I was hoping for something in Documentation/admin-guide, not in a
> > changelog that's hard to find.
>
> eventually yes.
>
> > >
> > > > Changing the capability th
On Tue, Aug 27, 2019 at 07:00:40PM -0700, Andy Lutomirski wrote:
>
> Let me put this a bit differently. Part of the point is that
> CAP_TRACING should allow a user or program to trace without being able
> to corrupt the system. CAP_BPF as you’ve proposed it *can* likely
> crash the system.
Really
On Wed, Aug 28, 2019 at 12:30:41PM +0900, Masami Hiramatsu wrote:
> > kprobes can be created in the tracefs filesystem (which is separate from
> > debugfs, tracefs just gets automatically mounted
> > in /sys/kernel/debug/tracing when debugfs is mounted) from the
> > kprobe_events file. /sys/kernel/
On Tue, Aug 27, 2019 at 05:55:41PM -0700, Andy Lutomirski wrote:
>
> I was hoping for something in Documentation/admin-guide, not in a
> changelog that's hard to find.
eventually yes.
> >
> > > Changing the capability that some existing operation requires could
> > > break existing programs. Th
On Tue, 27 Aug 2019 19:21:44 -0400
Steven Rostedt wrote:
> > Here's my proposal for CAP_TRACING, documentation-style:
> >
> > --- begin ---
> >
> > CAP_TRACING enables a task to use various kernel features to trace
> > running user programs and the kernel itself. CAP_TRACING also enables
> >
On Tue, 27 Aug 2019 18:12:59 -0700
Andy Lutomirski wrote:
> Too many slashes :/
>
> A group could work for v1. Maybe all the tools should get updated to use
> this path?
trace-cmd now does. In fact, if run as root, it will first check if
tracefs is mounted, and if not, it will try to mount it
> On Aug 27, 2019, at 5:55 PM, Andy Lutomirski wrote:
>
> On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov
> wrote:
>>
> From the previous discussion, you want to make progress toward solving
> a lot of problems with CAP_BPF. One of them was making BPF
> firewalling more generally useful. By
> On Aug 27, 2019, at 5:44 PM, Steven Rostedt wrote:
>
> On Tue, 27 Aug 2019 16:34:47 -0700
> Andy Lutomirski wrote:
>
CAP_TRACING does not override normal permissions on sysfs or debugfs.
This means that, unless a new interface for programming kprobes and
such is added, it do
On Tue, Aug 27, 2019 at 5:34 PM Alexei Starovoitov
wrote:
>
> On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> > [adding some security and tracing folks to cc]
> >
> > On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> > >
> > > Introduce CAP_BPF that allows loading all
On Tue, 27 Aug 2019 16:34:47 -0700
Andy Lutomirski wrote:
> > > CAP_TRACING does not override normal permissions on sysfs or debugfs.
> > > This means that, unless a new interface for programming kprobes and
> > > such is added, it does not directly allow use of kprobes.
> >
> > kprobes can be
On Tue, Aug 27, 2019 at 07:21:44PM -0400, Steven Rostedt wrote:
>
> At least for CAP_TRACING (if it were to allow read/write access
> to /sys/kernel/tracing), that would be very useful. It would be useful
> to those that basically own their machines, and want to trace their
> applications all the
On Tue, Aug 27, 2019 at 04:01:08PM -0700, Andy Lutomirski wrote:
> [adding some security and tracing folks to cc]
>
> On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> >
> > Introduce CAP_BPF that allows loading all types of BPF programs,
> > create most map types, load BTF, iterate pro
On Tue, Aug 27, 2019 at 4:21 PM Steven Rostedt wrote:
>
> On Tue, 27 Aug 2019 16:01:08 -0700
> Andy Lutomirski wrote:
>
> > [adding some security and tracing folks to cc]
> >
> > On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> > >
> > > Introduce CAP_BPF that allows loading all types
On Tue, 27 Aug 2019 16:01:08 -0700
Andy Lutomirski wrote:
> [adding some security and tracing folks to cc]
>
> On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
> >
> > Introduce CAP_BPF that allows loading all types of BPF programs,
> > create most map types, load BTF, iterate programs
[adding some security and tracing folks to cc]
On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov wrote:
>
> Introduce CAP_BPF that allows loading all types of BPF programs,
> create most map types, load BTF, iterate programs and maps.
> CAP_BPF alone is not enough to attach or run programs.
>
>
Introduce CAP_BPF that allows loading all types of BPF programs,
create most map types, load BTF, iterate programs and maps.
CAP_BPF alone is not enough to attach or run programs.
Networking:
CAP_BPF and CAP_NET_ADMIN are necessary to:
- attach to cgroup-bpf hooks like INET_INGRESS, INET_SOCK_CRE
46 matches
Mail list logo
