linux-kernel - Re: [PATCH bpf] bpf_trace: bail out from bpf_kprobe_multi_link

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: <CAADnVQ+2gwhcMht4PuDnDOFKY68Wsq8QFz4Y69NBX_TLaSexQQ@mail.gmail.com>
Date:   Tue, 10 May 2022 15:30:10 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Eugene Syromiatnikov <esyr@...hat.com>
Cc:     Jiri Olsa <jolsa@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [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@...hat.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@...hat.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.