On Wed, 19 Jan 2022 at 21:44, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > So how exactly is it going to be used with a pid provided by a tool? > > I'm guessing if bpf prog attaches to some syscall it will filter out > all events that don't match the pid. > Then when current_pid == user_provided_pid it will read memory. > In such case the prog can use bpf_get_current_task_btf() > and Kenny's bpf_access_process_vm(), right? Hi Alexei If I understand your suggestion correctly, one would call bpf_get_current_pid_tgid to get the pid and match it to the one passed by the user-space part of the BPF program, and then get the current task to pass to Kenny's helper (but wouldn't the existing bpf_copy_from_user be enough in this case?). I've had some further thoughts about my current and future use cases and I think they can be summarised in two scenarios: Scenario 1: A pid is passed to the user-space part of a BPF program and used to filter out as suggested above in kernel-space. Then Kenny's helper is enough. Scenario 2: A pid != current_pid is derived in the kernel part of BPF from somewhere in user-space and extra information needs to be retrieved from the remote process "represented" by this pid. I would expect many observability tools to fall within Scenario 1. However, a debugger might be an example of a tool that falls under Scenario 2 too. E.g. a function that takes a pid as an argument is traced and one wants to collect information from the VM of the process "identified" by it. Then the filtering out described above does not apply and we need either a helper like the one I'm proposing, or to expose find_get_task_by_vpid to BPF. More concretely, we might be tracing a native binary application that refers to a runtime like Python by pid and we might want to be able to return, e.g., the number of sub-interpreters or Python threads that are currently running, from events triggered for the native binary. Cheers, Gab
