Re: [PATCH bpf-next 1/1] bpf: Add bpf_copy_from_user_remote to read a process VM given its PID.

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Thu, Jan 20, 2022 at 8:56 AM Gabriele <phoenix1987@gmail.com> wrote:
>
> On Wed, 19 Jan 2022 at 21:44, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> 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.

Right. The existing bpf_copy_from_user will do here.

> 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.

How would bpf prog know the pid of the python interpreter?
Then how would it know the pids of the threads?
I'm not against exposing find_get_task_by_vpid(), but
we need to understand the real usage first.
If we do end up exposing find_get_task_by_vpid(), it's probably
best to do via refcnt-ed kfunc approach (unstable helpers).
For example: https://lore.kernel.org/all/20220114163953.1455836-7-memxor@gmail.com/