linux-kernel - Re: [PATCH -tip 1/1] x86/bpf: Fix BPF percpu accesses

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] [day] [month] [year] [list]

Message-ID: <CAEf4BzZt486SUMQq2DwnRX7n_XS9Rd1KYqMTFxg=6=QRZf=-xA@mail.gmail.com>
Date: Fri, 28 Feb 2025 09:19:50 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Brian Gerst <brgerst@...il.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, 
	Ingo Molnar <mingo@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH -tip 1/1] x86/bpf: Fix BPF percpu accesses

On Thu, Feb 27, 2025 at 11:53 AM Brian Gerst <brgerst@...il.com> wrote:
>
> Due to commit 9d7de2aa8b41 ("Use relative percpu offsets"), percpu
> addresses went from positive offsets from the GSBASE to negative kernel
> virtual addresses.  The BPF verifier has an optimization for x86-64 that
> loads the address of cpu_number into a register, but was only doing a
> 32-bit load which truncates negative addresses.  Change it to a 64-bit
> load so that the address is properly sign-extended.
>
> Fixes: 9d7de2aa8b41 ("Use relative percpu offsets")
> Signed-off-by: Brian Gerst <brgerst@...il.com>
> Cc: Andrii Nakryiko <andrii@...nel.org>
> Cc: Alexei Starovoitov <ast@...nel.org>
> ---
>  kernel/bpf/verifier.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 60611df77957..f4859516b190 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -21707,7 +21707,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
>                          * 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[0] = BPF_MOV64_IMM(BPF_REG_0, (u32)(unsigned long)&pcpu_hot.cpu_number);

wouldn't you need to at least drop the (u32) cast? Otherwise what's
really the point?

>                         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;
> --
> 2.48.1
>