On Mon, Nov 30, 2020 at 05:33:27AM +0100, Markus Ongyerth wrote: > On Sun, Nov 29, 2020, at 23:22, Alexei Starovoitov wrote: > > On Sun, Nov 29, 2020 at 10:38 AM Markus Ongyerth <bpf@xxxxxxxx> wrote: > > > > > > Hi, > > > > > > I've been looking into introspecting and possibly convincing an application to behave slightly different with bpf measures. > > > > > > I found `bpf_probe_user_write` but as far as I can tell, that only works for memory areas. > > > Is there an alternative that can be used on registers as well? > > > > fyi bpf_probe_write_user() warns in dmesg. > I've seen the note about that. I don't really mind, since it's not spammy but once when the code is loaded. > > That was done on purpose to avoid usage of this helper in production code. > > A new helper can be added to adjust user regs, but it will have similar warning. > > It's better to discuss the use case first. > > Do you envision user regs to be changed after uprobe in an arbitrary location > > or in some fixed place and only particular regs? > My current usecase needs to be able to set PT_REGS_PARM2 and PT_REG_PARM4 I think in specific function entry uprobes to modify an argument usually passed in a register by ABI. > And that's what I'd use for playing around with things in general I think. Arbitrary registers at arbitrary points sounds like fund but also way more dangerous. The uprobe can tap anywhere. Are you using USDT in such user space process? In other words does user process expect to be altered this way? In the past folks proposed an idea of user space tracepoints like USDT, but with less overhead. uprobe is quite slow to use in production for anything other than debugging. If we could add static_jump-like construct for user space to use and let kernel enable that jump that will do a syscall into kernel then we can allow bpf prog change syscall args and return arbitrary stuff back. Sort-of like USDT semaphore but without uprobe trap. This way user space will have predefined points in the code where it can expect changes to the flow of the code and data. On the other side hacking user's pt_regs from uprobe isn't such a big deal, since we allow probe_write_user already. If you can prepare a patch I think it has a good chance to land.
