Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote:
> 
> So in summary, I am trying to solve two (related) problems:
> 
> - Ensure that unprivileged tracing can obtain information about the task that
>   triggered a probe or event.  There will always be limitations but we can do
>   better than is available now.

I think unprivileged tracing is a huge topic on its own.
It's too easy to create security holes with such mechanism.
kprobe/tracepoints/etc have been historically root only and I don't see a way
for them to become unpriv.
imo the existing /proc/pid/status is already more powerful than
what you're proposing with gtrace context.

> - Allow tracing tools ab ability to provide actions to be performed when a
>   probe or event fires, beyond what the individual BPF program types allow
>   for the specific probe/event types (and do it in a generic manner, in a
>   sense encapsulating multiple probe/event types in a more generic tracing
>   context).

I think existing bpf tracing is generic whereas proposed gtrace is not generic at all.
'generic' is a loaded word. we can throw it back and forth and won't make
any forward progress. Let's focus on technical bits, ok?

> A patch I am currently working on ties into this (and I hope to get it ready
> sometime next week).  It builds on the support you already have for accessing
> packet data from the __sk_buff context.  If we can make this same functionality
> available to other contexts as well, my goal would be to make it possible for
> the generic tracing context to have a buffer (data and data_end members) that
> the BPF program can issue direct stores to as a means to allow a tracing
> program to control how data is written into the buffer. 

sounds like you're trying to reinvent bpf_perf_event_output() mechanism.

> But being able to do things like this without
> needing to touch the context of any other BPF program type is a great benefit
> to offer tracing tools, as far as I see it.

I still don't understand what you're referring to by 'things like this'
that somehow will be possible in the future, but not possible today.
Could you please give concrete example?




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux