All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Song Liu <song@kernel.org>, Song Liu <songliubraving@meta.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	"David S. Miller" <davem@davemloft.net>,
	David Ahern <dsahern@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Sami Tolvanen <samitolvanen@google.com>,
	Kees Cook <keescook@chromium.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	clang-built-linux <llvm@lists.linux.dev>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Joao Moreira <joao@overdrivepizza.com>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call
Date: Mon, 4 Dec 2023 19:33:54 +0100	[thread overview]
Message-ID: <20231204183354.GC7299@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231204181614.GA7299@noisy.programming.kicks-ass.net>

On Mon, Dec 04, 2023 at 07:16:14PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 04, 2023 at 06:25:34PM +0100, Jiri Olsa wrote:
> 
> > that boots properly for me but gives crash below when running bpf tests
> 
> OK, more funnies..
> 
> > [  482.145182][  T699] RIP: 0010:bpf_for_each_array_elem+0xbb/0x120
> > [  482.145672][  T699] Code: 4c 01 f5 89 5c 24 04 4c 89 e7 48 8d 74 24 04 48 89 ea 4c 89 fd 4c 89 f9 45 31 c0 4d 89 eb 41 ba ef 86 cd 67 45 03 53 f1 74 02 <0f> 0b 41 ff d3 0f 1f 00 48 85 c0 75 0e 48 8d 43 01 41 8b 4c 24 24
> > [  482.147221][  T699] RSP: 0018:ffffc900017e3e88 EFLAGS: 00010217
> > [  482.147702][  T699] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc900017e3ed8
> > [  482.152162][  T699] RDX: ffff888152eb0210 RSI: ffffc900017e3e8c RDI: ffff888152eb0000
> > [  482.152770][  T699] RBP: ffffc900017e3ed8 R08: 0000000000000000 R09: 0000000000000000
> > [  482.153350][  T699] R10: 000000004704ef28 R11: ffffffffa0012774 R12: ffff888152eb0000
> > [  482.153951][  T699] R13: ffffffffa0012774 R14: ffff888152eb0210 R15: ffffc900017e3ed8
> > [  482.154554][  T699] FS:  00007fa60d4fdd00(0000) GS:ffff88846d200000(0000) knlGS:0000000000000000
> > [  482.155138][  T699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  482.155564][  T699] CR2: 00007fa60d7d8000 CR3: 00000001502a2005 CR4: 0000000000770ef0
> > [  482.156095][  T699] PKRU: 55555554
> > [  482.156349][  T699] Call Trace:
> > [  482.156596][  T699]  <TASK>
> > [  482.156816][  T699]  ? __die_body+0x68/0xb0
> > [  482.157138][  T699]  ? die+0xba/0xe0
> > [  482.157456][  T699]  ? do_trap+0xa5/0x180
> > [  482.157826][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.158277][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.158711][  T699]  ? do_error_trap+0xc4/0x140
> > [  482.159052][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.159506][  T699]  ? handle_invalid_op+0x2c/0x40
> > [  482.159906][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.160990][  T699]  ? exc_invalid_op+0x38/0x60
> > [  482.161375][  T699]  ? asm_exc_invalid_op+0x1a/0x20
> > [  482.161788][  T699]  ? 0xffffffffa0012774
> > [  482.162149][  T699]  ? 0xffffffffa0012774
> > [  482.162513][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.162905][  T699]  bpf_prog_ca45ea7f9cb8ac1a_inner_map+0x94/0x98
> > [  482.163471][  T699]  bpf_trampoline_6442549234+0x47/0x1000
> 
> Looks like this trips an #UD, I'll go try and figure out what this
> bpf_for_each_array_elem() does to cause this. Looks like it has an
> indirect call, could be the callback_fn thing has a CFI mis-match.

So afaict this is used through bpf_for_each_map_elem(), where the
argument still is properly callback_fn. However, in the desriptor
bpf_for_each_map_elem_proto the argument gets described as:
ARG_PTR_TO_FUNC, which in turn has a comment like:

  ARG_PTR_TO_FUNC,        /* pointer to a bpf program function */

Which to me sounds like there is definite type punning involved. The
call in bpf_for_each_array_elem() is a regular C indirect call, which
gets adorned with the kCFI magic.

But I doubt the BPF function that gets used gets the correct matching
bits on.

TL;DR, I think this is a pre-existing problem with kCFI + eBPF and not
caused by my patches.

Could any of you bpf knowledgeable folks please explain me exactly what
gets used as the function pointer in this case? -- I'm not sure I can
follow along well enough to begin looking for a solution at this point
:/

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Song Liu <song@kernel.org>, Song Liu <songliubraving@meta.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	"David S. Miller" <davem@davemloft.net>,
	David Ahern <dsahern@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Sami Tolvanen <samitolvanen@google.com>,
	Kees Cook <keescook@chromium.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	clang-built-linux <llvm@lists.linux.dev>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Joao Moreira <joao@overdrivepizza.com>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call
Date: Mon, 4 Dec 2023 19:33:54 +0100	[thread overview]
Message-ID: <20231204183354.GC7299@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231204181614.GA7299@noisy.programming.kicks-ass.net>

On Mon, Dec 04, 2023 at 07:16:14PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 04, 2023 at 06:25:34PM +0100, Jiri Olsa wrote:
> 
> > that boots properly for me but gives crash below when running bpf tests
> 
> OK, more funnies..
> 
> > [  482.145182][  T699] RIP: 0010:bpf_for_each_array_elem+0xbb/0x120
> > [  482.145672][  T699] Code: 4c 01 f5 89 5c 24 04 4c 89 e7 48 8d 74 24 04 48 89 ea 4c 89 fd 4c 89 f9 45 31 c0 4d 89 eb 41 ba ef 86 cd 67 45 03 53 f1 74 02 <0f> 0b 41 ff d3 0f 1f 00 48 85 c0 75 0e 48 8d 43 01 41 8b 4c 24 24
> > [  482.147221][  T699] RSP: 0018:ffffc900017e3e88 EFLAGS: 00010217
> > [  482.147702][  T699] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc900017e3ed8
> > [  482.152162][  T699] RDX: ffff888152eb0210 RSI: ffffc900017e3e8c RDI: ffff888152eb0000
> > [  482.152770][  T699] RBP: ffffc900017e3ed8 R08: 0000000000000000 R09: 0000000000000000
> > [  482.153350][  T699] R10: 000000004704ef28 R11: ffffffffa0012774 R12: ffff888152eb0000
> > [  482.153951][  T699] R13: ffffffffa0012774 R14: ffff888152eb0210 R15: ffffc900017e3ed8
> > [  482.154554][  T699] FS:  00007fa60d4fdd00(0000) GS:ffff88846d200000(0000) knlGS:0000000000000000
> > [  482.155138][  T699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  482.155564][  T699] CR2: 00007fa60d7d8000 CR3: 00000001502a2005 CR4: 0000000000770ef0
> > [  482.156095][  T699] PKRU: 55555554
> > [  482.156349][  T699] Call Trace:
> > [  482.156596][  T699]  <TASK>
> > [  482.156816][  T699]  ? __die_body+0x68/0xb0
> > [  482.157138][  T699]  ? die+0xba/0xe0
> > [  482.157456][  T699]  ? do_trap+0xa5/0x180
> > [  482.157826][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.158277][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.158711][  T699]  ? do_error_trap+0xc4/0x140
> > [  482.159052][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.159506][  T699]  ? handle_invalid_op+0x2c/0x40
> > [  482.159906][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.160990][  T699]  ? exc_invalid_op+0x38/0x60
> > [  482.161375][  T699]  ? asm_exc_invalid_op+0x1a/0x20
> > [  482.161788][  T699]  ? 0xffffffffa0012774
> > [  482.162149][  T699]  ? 0xffffffffa0012774
> > [  482.162513][  T699]  ? bpf_for_each_array_elem+0xbb/0x120
> > [  482.162905][  T699]  bpf_prog_ca45ea7f9cb8ac1a_inner_map+0x94/0x98
> > [  482.163471][  T699]  bpf_trampoline_6442549234+0x47/0x1000
> 
> Looks like this trips an #UD, I'll go try and figure out what this
> bpf_for_each_array_elem() does to cause this. Looks like it has an
> indirect call, could be the callback_fn thing has a CFI mis-match.

So afaict this is used through bpf_for_each_map_elem(), where the
argument still is properly callback_fn. However, in the desriptor
bpf_for_each_map_elem_proto the argument gets described as:
ARG_PTR_TO_FUNC, which in turn has a comment like:

  ARG_PTR_TO_FUNC,        /* pointer to a bpf program function */

Which to me sounds like there is definite type punning involved. The
call in bpf_for_each_array_elem() is a regular C indirect call, which
gets adorned with the kCFI magic.

But I doubt the BPF function that gets used gets the correct matching
bits on.

TL;DR, I think this is a pre-existing problem with kCFI + eBPF and not
caused by my patches.

Could any of you bpf knowledgeable folks please explain me exactly what
gets used as the function pointer in this case? -- I'm not sure I can
follow along well enough to begin looking for a solution at this point
:/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-12-04 18:34 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 13:36 [PATCH v2 0/2] x86/bpf: Fix FineIBT vs eBPF Peter Zijlstra
2023-11-30 13:36 ` Peter Zijlstra
2023-11-30 13:36 ` [PATCH v2 1/2] cfi: Flip headers Peter Zijlstra
2023-11-30 13:36   ` Peter Zijlstra
2023-12-04 19:18   ` Sami Tolvanen
2023-12-04 19:18     ` Sami Tolvanen
2023-11-30 13:36 ` [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call Peter Zijlstra
2023-11-30 13:36   ` Peter Zijlstra
2023-12-03 22:56   ` Alexei Starovoitov
2023-12-03 22:56     ` Alexei Starovoitov
2023-12-04  9:13     ` Peter Zijlstra
2023-12-04  9:13       ` Peter Zijlstra
2023-12-04 11:11       ` Peter Zijlstra
2023-12-04 11:11         ` Peter Zijlstra
2023-12-04 12:52         ` Peter Zijlstra
2023-12-04 12:52           ` Peter Zijlstra
2023-12-04 17:25           ` Jiri Olsa
2023-12-04 17:25             ` Jiri Olsa
2023-12-04 18:16             ` Peter Zijlstra
2023-12-04 18:16               ` Peter Zijlstra
2023-12-04 18:33               ` Peter Zijlstra [this message]
2023-12-04 18:33                 ` Peter Zijlstra
2023-12-04 18:58                 ` Sami Tolvanen
2023-12-04 18:58                   ` Sami Tolvanen
2023-12-05  1:18                 ` Alexei Starovoitov
2023-12-05  1:18                   ` Alexei Starovoitov
2023-12-06 15:35                   ` Peter Zijlstra
2023-12-06 15:35                     ` Peter Zijlstra
2023-12-06 16:38                   ` Peter Zijlstra
2023-12-06 16:38                     ` Peter Zijlstra
2023-12-06 18:37                     ` Peter Zijlstra
2023-12-06 18:37                       ` Peter Zijlstra
2023-12-06 21:39                       ` Alexei Starovoitov
2023-12-06 21:39                         ` Alexei Starovoitov
2023-12-07  9:31                         ` Peter Zijlstra
2023-12-07  9:31                           ` Peter Zijlstra
2023-12-07 22:32                           ` Alexei Starovoitov
2023-12-07 22:32                             ` Alexei Starovoitov
2023-12-08 10:29                             ` Peter Zijlstra
2023-12-08 10:29                               ` Peter Zijlstra
2023-12-08 13:40                               ` Peter Zijlstra
2023-12-08 13:40                                 ` Peter Zijlstra
2023-12-08 17:21                                 ` Peter Zijlstra
2023-12-08 17:21                                   ` Peter Zijlstra
2023-12-08 19:40                                   ` Alexei Starovoitov
2023-12-08 19:40                                     ` Alexei Starovoitov
2023-12-08 20:27                                     ` Peter Zijlstra
2023-12-08 20:27                                       ` Peter Zijlstra
2023-12-08 20:35                                     ` Peter Zijlstra
2023-12-08 20:35                                       ` Peter Zijlstra
2023-12-08 20:41                                       ` Alexei Starovoitov
2023-12-08 20:41                                         ` Alexei Starovoitov
2023-12-08 20:52                                         ` Peter Zijlstra
2023-12-08 20:52                                           ` Peter Zijlstra
2023-12-08 20:58                                           ` Alexei Starovoitov
2023-12-08 20:58                                             ` Alexei Starovoitov
2023-12-08 22:45                                             ` Peter Zijlstra
2023-12-08 22:45                                               ` Peter Zijlstra
2023-12-09  4:51                                               ` Alexei Starovoitov
2023-12-09  4:51                                                 ` Alexei Starovoitov
2023-12-08 19:32                                 ` Alexei Starovoitov
2023-12-08 19:32                                   ` Alexei Starovoitov
2023-12-08 20:18                                   ` Peter Zijlstra
2023-12-08 20:18                                     ` Peter Zijlstra
2023-12-08 20:45                                     ` Alexei Starovoitov
2023-12-08 20:45                                       ` Alexei Starovoitov
2023-12-08 20:56                                       ` Peter Zijlstra
2023-12-08 20:56                                         ` Peter Zijlstra
2023-12-08 21:04                                         ` Alexei Starovoitov
2023-12-08 21:04                                           ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231204183354.GC7299@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=haoluo@google.com \
    --cc=hpa@zytor.com \
    --cc=joao@overdrivepizza.com \
    --cc=john.fastabend@gmail.com \
    --cc=jpoimboe@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=olsajiri@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=samitolvanen@google.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=songliubraving@meta.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.