linux-kernel - Re: [PATCH] bpf: do not inline bpf_get_smp_processor_id() with CONFIG

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+1=3U_gusnrfVD3QrQirg5Bzwawje9nD2f-nvrYJH=JA@mail.gmail.com>
Date: Mon, 16 Dec 2024 10:33:43 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: Andrea Righi <arighi@...dia.com>, Daniel Borkmann <daniel@...earbox.net>, 
	Alexei Starovoitov <ast@...nel.org>, John Fastabend <john.fastabend@...il.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: do not inline bpf_get_smp_processor_id() with
 CONFIG_SMP disabled

On Mon, Dec 16, 2024 at 10:27 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> On Mon, 2024-12-16 at 18:24 +0100, Andrea Righi wrote:
> > On Mon, Dec 16, 2024 at 05:16:33PM +0100, Daniel Borkmann wrote:
> > > On 12/16/24 11:46 AM, Andrea Righi wrote:
> > > > Calling bpf_get_smp_processor_id() in a kernel with CONFIG_SMP disabled
> > > > can trigger the following bug, as pcpu_hot is unavailable:
> > > >
> > > > [    8.471774] BUG: unable to handle page fault for address: 00000000936a290c
> > > > [    8.471849] #PF: supervisor read access in kernel mode
> > > > [    8.471881] #PF: error_code(0x0000) - not-present page
> > > >
> > > > Fix by preventing the inlining of bpf_get_smp_processor_id() when
> > > > CONFIG_SMP disabled.
> > > >
> > > > Fixes: 1ae6921009e5 ("bpf: inline bpf_get_smp_processor_id() helper")
> > > > Signed-off-by: Andrea Righi <arighi@...dia.com>
> > >
> > > lgtm, but can't we instead do sth like this :
> > >
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index f7f892a52a37..761c70899754 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -21281,11 +21281,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > >                      * changed in some incompatible and hard to support
> > >                      * way, it's fine to back out this inlining logic
> > >                      */
> > > +#ifdef CONFIG_SMP
> > >                     insn_buf[0] = BPF_MOV32_IMM(BPF_REG_0, (u32)(unsigned long)&pcpu_hot.cpu_number);
> > >                     insn_buf[1] = BPF_MOV64_PERCPU_REG(BPF_REG_0, BPF_REG_0);
> > >                     insn_buf[2] = BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, 0);
> > >                     cnt = 3;
> > > -
> > > +#else
> > > +                   BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_0),
> > > +                   cnt = 1;
> > > +#endif
> > >                     new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > >                     if (!new_prog)
> > >                             return -ENOMEM;
> >
> > That works as well (just tested) and it's probably better since we're
> > basically inlining the return 0. Do you want me to send a v2 with this?
>
> I think both Andrea's and Daniel's versions of the fix are good.
> Note, however, that I missed one more configuration variable when
> making bpf_get_smp_processor_id() inlinable: CONFIG_DEBUG_PREEMPT.
>
> Helper body:
>
>     BPF_CALL_0(bpf_get_smp_processor_id)
>     {
>         return smp_processor_id();
>     }
>
> smp_processor_id definition:
>
>     #ifdef CONFIG_DEBUG_PREEMPT
>       extern unsigned int debug_smp_processor_id(void);
>     # define smp_processor_id() debug_smp_processor_id()
>     #else
>     # define smp_processor_id() __smp_processor_id()
>     #endif

No. It's fine as-is.
We inline raw_smp_processor_id().