All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Markus Ongyerth <bpf@ongy.net>
Cc: bpf <bpf@vger.kernel.org>
Subject: Re: HELP: bpf_probe_user_write for registers
Date: Mon, 30 Nov 2020 18:27:55 -0800	[thread overview]
Message-ID: <20201201022755.puubc7u3kbepanig@ast-mbp> (raw)
In-Reply-To: <3bb48133-2853-41fd-9bc4-8ea7c6d5bd5b@www.fastmail.com>

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@ongy.net> 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.

      reply	other threads:[~2020-12-01  2:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-29 18:34 HELP: bpf_probe_user_write for registers Markus Ongyerth
2020-11-29 22:22 ` Alexei Starovoitov
2020-11-30  4:33   ` Markus Ongyerth
2020-12-01  2:27     ` Alexei Starovoitov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201201022755.puubc7u3kbepanig@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=bpf@ongy.net \
    --cc=bpf@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.