Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220506142148.GA24802@asgard.redhat.com> <CAADnVQKNkEX-caBjozegRaOb67g1HNOHn1e-enRk_s-7Gtt=gg@mail.gmail.com>
 <20220510184155.GA8295@asgard.redhat.com>
In-Reply-To: <20220510184155.GA8295@asgard.redhat.com>
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date:   Tue, 10 May 2022 15:30:10 -0700
Message-ID: <CAADnVQ+2gwhcMht4PuDnDOFKY68Wsq8QFz4Y69NBX_TLaSexQQ@mail.gmail.com>
Subject: Re: [PATCH bpf] bpf_trace: bail out from bpf_kprobe_multi_link_attach
 when in compat
To:     Eugene Syromiatnikov <esyr@redhat.com>
Cc:     Jiri Olsa <jolsa@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, May 10, 2022 at 11:42 AM Eugene Syromiatnikov <esyr@redhat.com> wro=
te:
>
> 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> w=
rote:
> > >
> > > 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 us=
erspace
> pointers to be passed (for example, syms points to an array of userspace
> pointers=E2=80=94character strings; same goes for addrs, but with generic=
 userspace
> pointers) without regard to possible difference in the pointer size in ca=
se
> 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) !=3D 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.