linux-kernel - Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240408125401.d4f100d184b11bc01fcd0308@kernel.org>
Date: Mon, 8 Apr 2024 12:54:01 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Jiri Olsa <olsajiri@...il.com>, Andrii Nakryiko
 <andrii.nakryiko@...il.com>, Steven Rostedt <rostedt@...dmis.org>, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, Song Liu
 <songliubraving@...com>, Yonghong Song <yhs@...com>, John Fastabend
 <john.fastabend@...il.com>, Peter Zijlstra <peterz@...radead.org>, Thomas
 Gleixner <tglx@...utronix.de>, "Borislav Petkov (AMD)" <bp@...en8.de>,
 x86@...nel.org, linux-api@...r.kernel.org
Subject: Re: [PATCHv2 1/3] uprobe: Add uretprobe syscall to speed up return
 probe

On Sat, 6 Apr 2024 19:55:59 +0200
Oleg Nesterov <oleg@...hat.com> wrote:

> On 04/06, Masami Hiramatsu wrote:
> >
> > On Fri, 5 Apr 2024 13:02:30 +0200
> > Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > > With or without this patch userpace can also do
> > >
> > > 	foo() { <-- retprobe1
> > > 		bar() {
> > > 			jump to xol_area
> > > 		}
> > > 	}
> > >
> > > handle_trampoline() will handle retprobe1.
> >
> > This is OK because the execution path has been changed to trampoline,
> 
> Agreed, in this case the misuse is more clear. But please see below.
> 
> > but the above will continue running bar() after sys_uretprobe().
> 
> .. and most probably crash

Yes, unless it returns with longjmp(). (but this is rare case and
maybe malicious program.)

> 
> > > sigreturn() can be "improved" too. Say, it could validate sigcontext->ip
> > > and return -EINVAL if this addr is not valid. But why?
> >
> > Because sigreturn() never returns, but sys_uretprobe() will return.
> 
> You mean, sys_uretprobe() returns to the next insn after syscall.
> 
> Almost certainly yes, but this is not necessarily true. If one of consumers
> changes regs->sp sys_uretprobe() "returns" to another location, just like
> sys_rt_sigreturn().
> 
> That said.
> 
> Masami, it is not that I am trying to prove that you are "wrong" ;) No.
> 
> I see your points even if I am biased, I understand that my objections are
> not 100% "fair".
> 
> I am just trying to explain why, rightly or not, I care much less about the
> abuse of sys_uretprobe().

I would like to clear that the abuse of this syscall will not possible to harm
the normal programs, and even if it is used by malicious code (e.g. injected by
stack overflow) it doesn't cause a problem. At least thsese points are cleared,
and documented. it is easier to push it as new Linux API.

Thank you,

> 
> Thanks!
> 
> Oleg.
> 
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>