On Wed, Jul 10, 2019 at 10:15:44AM -0400, Joel Fernandes (Google) wrote: > Hi, why are you cc-ing the whole world for this patch set? I'll reply to all as well, but I suspect a bunch of folks consider it spam. Please read Documentation/bpf/bpf_devel_QA.rst Also, I think, netdev@vger rejects emails with 80+ characters in cc as spam, so I'm not sure this set reached public mailing lists. > These patches make it possible to attach BPF programs directly to tracepoints > using ftrace (/sys/kernel/debug/tracing) without needing the process doing the > attach to be alive. This has the following benefits: > > 1. Simplified Security: In Android, we have finer-grained security controls to > specific ftrace trace events using SELinux labels. We control precisely who is > allowed to enable an ftrace event already. By adding a node to ftrace for > attaching BPF programs, we can use the same mechanism to further control who is > allowed to attach to a trace event. > > 2. Process lifetime: In Android we are adding usecases where a tracing program > needs to be attached all the time to a tracepoint, for the full life time of > the system. Such as to gather statistics where there no need for a detach for > the full system lifetime. With perf or bpf(2)'s BPF_RAW_TRACEPOINT_OPEN, this > means keeping a process alive all the time. However, in Android our BPF loader > currently (for hardeneded security) involves just starting a process at boot > time, doing the BPF program loading, and then pinning them to /sys/fs/bpf. We > don't keep this process alive all the time. It is more suitable to do a > one-shot attach of the program using ftrace and not need to have a process > alive all the time anymore for this. Such process also needs elevated > privileges since tracepoint program loading currently requires CAP_SYS_ADMIN > anyway so by design Android's bpfloader runs once at init and exits. > > This series add a new bpf file to /sys/kernel/debug/tracing/events/X/Y/bpf > The following commands can be written into it: > attach:<fd> Attaches BPF prog fd to tracepoint > detach:<fd> Detaches BPF prog fd to tracepoint Looks like, to detach a program the user needs to read a text file, parse bpf prog id from text into binary. Then call fd_from_id bpf syscall, get a binary FD, convert it back to text and write as a text back into this file. I think this is just a single example why text based apis are not accepted in bpf anymore. Through the patch set you call it ftrace. As far as I can see, this set has zero overlap with ftrace. There is no ftrace-bpf connection here at all that we discussed in the past Steven. It's all quite confusing. I suggest android to solve sticky raw_tracepoint problem with user space deamon. The reasons, you point out why user daemon cannot be used, sound weak to me. Another acceptable solution would be to introduce pinning of raw_tp objects. bpf progs and maps can be pinned in bpffs already. Pinning raw_tp would be natural extension.
