lkml.org 
[lkml]   [2022]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH bpf] bpf_trace: bail out from bpf_kprobe_multi_link_attach when in compat
On Tue, May 10, 2022 at 11:42 AM Eugene Syromiatnikov <esyr@redhat.com> wrote:
>
> On Tue, May 10, 2022 at 11:10:35AM -0700, Alexei Starovoitov wrote:
> > On Fri, May 6, 2022 at 7:22 AM Eugene Syromiatnikov <esyr@redhat.com> wrote:
> > >
> > > Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels
> > > for whatever reason,
> >
> > Jiri,
> > why did you add this restriction?
> >
> > > having it enabled for compat processes on 64-bit
> > > kernels makes even less sense due to discrepances in the type sizes
> > > that it does not handle.
> >
> > I don't follow this logic.
> > bpf progs are always 64-bit. Even when user space is 32-bit.
> > Jiri's check is for the kernel.
>
> The interface as defined (and implemented in libbpf) expects arrays of userspace
> pointers to be passed (for example, syms points to an array of userspace
> pointers—character strings; same goes for addrs, but with generic userspace
> pointers) without regard to possible difference in the pointer size in case
> of compat userspace.

I see. So kprobe_multi.syms and kprobe_multi.addrs will be 'long'
and 32-bit user space will have an issue with the 64-bit kernel.
Let's fix it properly.
We can remove sizeof(u64) != sizeof(void *) and keep libbpf as-is
by keeping syms and addrs 'long' in uapi.
As far as I can see 32-bit user space on a 32-bit kernel
should work with existing code.
in_compat_syscall() can be used to extend addrs/syms.

\
 
 \ /
  Last update: 2022-05-11 00:31    [W:0.070 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site