linux-kernel - Re: [PATCHv2 perf/core 08/22] uprobes/x86: Add mapping for optimized uprobe trampolines

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: <aCbtqalKPGMMvxpk@krava>
Date: Fri, 16 May 2025 09:47:53 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Oleg Nesterov <oleg@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	x86@...nel.org, Song Liu <songliubraving@...com>,
	Yonghong Song <yhs@...com>,
	John Fastabend <john.fastabend@...il.com>,
	Hao Luo <haoluo@...gle.com>, Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Alan Maguire <alan.maguire@...cle.com>,
	David Laight <David.Laight@...lab.com>,
	Thomas Weißschuh <thomas@...ch.de>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCHv2 perf/core 08/22] uprobes/x86: Add mapping for optimized
 uprobe trampolines

On Thu, May 15, 2025 at 10:22:51AM -0700, Andrii Nakryiko wrote:
> On Thu, May 15, 2025 at 5:13 AM Jiri Olsa <jolsa@...nel.org> wrote:
> >
> > Adding support to add special mapping for user space trampoline with
> > following functions:
> >
> >   uprobe_trampoline_get - find or add uprobe_trampoline
> >   uprobe_trampoline_put - remove or destroy uprobe_trampoline
> >
> > The user space trampoline is exported as arch specific user space special
> > mapping through tramp_mapping, which is initialized in following changes
> > with new uprobe syscall.
> >
> > The uprobe trampoline needs to be callable/reachable from the probed address,
> > so while searching for available address we use is_reachable_by_call function
> > to decide if the uprobe trampoline is callable from the probe address.
> >
> > All uprobe_trampoline objects are stored in uprobes_state object and are
> > cleaned up when the process mm_struct goes down. Adding new arch hooks
> > for that, because this change is x86_64 specific.
> >
> > Locking is provided by callers in following changes.
> >
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> > ---
> >  arch/x86/kernel/uprobes.c | 115 ++++++++++++++++++++++++++++++++++++++
> >  include/linux/uprobes.h   |   6 ++
> >  kernel/events/uprobes.c   |  10 ++++
> >  kernel/fork.c             |   1 +
> >  4 files changed, 132 insertions(+)
> >
> 
> [...]
> 
> > +static unsigned long find_nearest_page(unsigned long vaddr)
> > +{
> > +       struct vm_unmapped_area_info info = {
> > +               .length     = PAGE_SIZE,
> > +               .align_mask = ~PAGE_MASK,
> > +               .flags      = VM_UNMAPPED_AREA_TOPDOWN,
> > +               .low_limit  = 0,
> 
> would this, technically, allow to allocate memory at NULL (0x0000)
> address? should this start at PAGE_SIZE?

of course I overlooked that, but looks like it's ok because of the
mmap_min_addr, which is used as the actual low limit.. anyway I think
it's better to be explicit, so I'll put the PAGE_SIZE in here

thanks,
jirka

> 
> > +               .high_limit = ULONG_MAX,
> > +       };
> > +       unsigned long limit, call_end = vaddr + 5;
> > +
> > +       if (!check_add_overflow(call_end, INT_MIN, &limit))
> > +               info.low_limit = limit;
> > +       if (!check_add_overflow(call_end, INT_MAX, &limit))
> > +               info.high_limit = limit;
> > +       return vm_unmapped_area(&info);
> > +}
> 
> [...]