public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <olsajiri@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Borislav Petkov (AMD)" <bp@alien8.de>,
	x86@kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe
Date: Fri, 5 Apr 2024 10:56:15 +0200	[thread overview]
Message-ID: <Zg-8r63tPSkuhN7p@krava> (raw)
In-Reply-To: <20240405102203.825c4a2e9d1c2be5b2bffe96@kernel.org>

On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> On Thu, 4 Apr 2024 18:11:09 +0200
> Oleg Nesterov <oleg@redhat.com> wrote:
> 
> > On 04/05, Masami Hiramatsu wrote:
> > >
> > > Can we make this syscall and uprobe behavior clearer? As you said, if
> > > the application use sigreturn or longjump, it may skip returns and
> > > shadow stack entries are left in the kernel. In such cases, can uretprobe
> > > detect it properly, or just crash the process (or process runs wrongly)?
> > 
> > Please see the comment in handle_trampoline(), it tries to detect this case.
> > This patch should not make any difference.
> 
> I think you mean this loop will skip and discard the stacked return_instance
> to find the valid one.
> 
> ----
>         do {
>                 /*
>                  * We should throw out the frames invalidated by longjmp().
>                  * If this chain is valid, then the next one should be alive
>                  * or NULL; the latter case means that nobody but ri->func
>                  * could hit this trampoline on return. TODO: sigaltstack().
>                  */
>                 next = find_next_ret_chain(ri);
>                 valid = !next || arch_uretprobe_is_alive(next, RP_CHECK_RET, regs);
> 
>                 instruction_pointer_set(regs, ri->orig_ret_vaddr);
>                 do {
>                         if (valid)
>                                 handle_uretprobe_chain(ri, regs);
>                         ri = free_ret_instance(ri);
>                         utask->depth--;
>                 } while (ri != next);
>         } while (!valid);
> ----
> 
> I think this expects setjmp/longjmp as below
> 
> foo() { <- retprobe1
> 	setjmp()
> 	bar() { <- retprobe2
> 		longjmp()
> 	}
> } <- return to trampoline
> 
> In this case, we need to skip retprobe2's instance.
> My concern is, if we can not find appropriate return instance, what happen?
> e.g.
> 
> foo() { <-- retprobe1
>    bar() { # sp is decremented
>        sys_uretprobe() <-- ??
>     }
> }
> 
> It seems sys_uretprobe() will handle retprobe1 at that point instead of
> SIGILL.

yes, and I think it's fine, you get the consumer called in wrong place,
but it's your fault and kernel won't crash

this can be fixed by checking the syscall is called from the trampoline
and prevent handle_trampoline call if it's not

> 
> Can we avoid this with below strict check?
> 
> if (ri->stack != regs->sp + expected_offset)
> 	goto sigill;

hm the current uprobe 'alive' check makes sure the return_instance is above
or at the same stack address, not sure we can match it exactly, need to think
about that more

> 
> expected_offset should be 16 (push * 3 - ret) on x64 if we ri->stack is the
> regs->sp right after call.

the syscall trampoline already updates the regs->sp before calling
handle_trampoline

        regs->sp += sizeof(r11_cx_ax);

jirka

  reply	other threads:[~2024-04-05  8:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  9:32 [PATCHv2 0/3] uprobe: uretprobe speed up Jiri Olsa
2024-04-02  9:33 ` [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe Jiri Olsa
2024-04-03  1:07   ` Masami Hiramatsu
2024-04-03  9:47     ` Jiri Olsa
2024-04-03 13:56       ` Oleg Nesterov
2024-04-03 14:09       ` Masami Hiramatsu
2024-04-03 14:49         ` Oleg Nesterov
2024-04-03 16:58         ` Andrii Nakryiko
2024-04-04  0:58           ` Masami Hiramatsu
2024-04-04  2:00             ` Andrii Nakryiko
2024-04-04 11:58               ` Jiri Olsa
2024-04-04 16:06                 ` Masami Hiramatsu
2024-04-04 15:54               ` Masami Hiramatsu
2024-04-04 16:11                 ` Oleg Nesterov
2024-04-05  1:22                   ` Masami Hiramatsu
2024-04-05  8:56                     ` Jiri Olsa [this message]
2024-04-05 11:02                       ` Oleg Nesterov
2024-04-06  3:05                         ` Masami Hiramatsu
2024-04-06 17:55                           ` Oleg Nesterov
2024-04-08  3:54                             ` Masami Hiramatsu
2024-04-08 16:02                         ` Jiri Olsa
2024-04-08 16:22                           ` Oleg Nesterov
2024-04-09 12:06                             ` Jiri Olsa
2024-04-09  0:34                           ` Masami Hiramatsu
2024-04-09  7:57                             ` Jiri Olsa
2024-04-08  3:16                       ` Masami Hiramatsu
2024-04-15  8:25   ` Jiri Olsa
2024-04-18 18:34     ` Andrii Nakryiko
2024-04-02  9:33 ` [PATCHv2 bpf-next 2/3] selftests/bpf: Add uretprobe test for regs integrity Jiri Olsa
2024-04-02  9:33 ` [PATCHv2 bpf-next 3/3] selftests/bpf: Add uretprobe test for regs changes Jiri Olsa

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=Zg-8r63tPSkuhN7p@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=songliubraving@fb.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yhs@fb.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox