bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Anton Protopopov <a.s.protopopov@gmail.com>,
	bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Anton Protopopov <aspsk@isovalent.com>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	Quentin Monnet <qmo@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>
Subject: Re: [RFC bpf-next 6/9] bpf: workaround llvm behaviour with indirect jumps
Date: Wed, 18 Jun 2025 04:04:21 -0700	[thread overview]
Message-ID: <5be2b20d4190e6c2aed7386a350bccc3eaa79535.camel@gmail.com> (raw)
In-Reply-To: <20250615085943.3871208-7-a.s.protopopov@gmail.com>

On Sun, 2025-06-15 at 08:59 +0000, Anton Protopopov wrote:
> When indirect jumps are enabled in LLVM, it might generate
> unreachable instructions. For example, the following code
> 
>     SEC("syscall") int foo(struct simple_ctx *ctx)
>     {
>             switch (ctx->x) {
>             case 0:
>                     ret_user = 2;
>                     break;
>             case 11:
>                     ret_user = 3;
>                     break;
>             case 27:
>                     ret_user = 4;
>                     break;
>             case 31:
>                     ret_user = 5;
>                     break;
>             default:
>                     ret_user = 19;
>                     break;
>             }
> 
>             return 0;
>     }
> 
> compiles into
> 
>     <foo>:
>     ;       switch (ctx->x) {
>          224:       79 11 00 00 00 00 00 00 r1 = *(u64 *)(r1 + 0x0)
>          225:       25 01 0f 00 1f 00 00 00 if r1 > 0x1f goto +0xf <foo+0x88>
>          226:       67 01 00 00 03 00 00 00 r1 <<= 0x3
>          227:       18 02 00 00 a8 00 00 00 00 00 00 00 00 00 00 00 r2 = 0xa8 ll
>                     0000000000000718:  R_BPF_64_64  .rodata
>          229:       0f 12 00 00 00 00 00 00 r2 += r1
>          230:       79 21 00 00 00 00 00 00 r1 = *(u64 *)(r2 + 0x0)
>          231:       0d 01 00 00 00 00 00 00 gotox r1
>          232:       05 00 08 00 00 00 00 00 goto +0x8 <foo+0x88>
>          233:       b7 01 00 00 02 00 00 00 r1 = 0x2
>     ;       switch (ctx->x) {
>          234:       05 00 07 00 00 00 00 00 goto +0x7 <foo+0x90>
>          235:       b7 01 00 00 04 00 00 00 r1 = 0x4
>     ;               break;
>          236:       05 00 05 00 00 00 00 00 goto +0x5 <foo+0x90>
>          237:       b7 01 00 00 03 00 00 00 r1 = 0x3
>     ;               break;
>          238:       05 00 03 00 00 00 00 00 goto +0x3 <foo+0x90>
>          239:       b7 01 00 00 05 00 00 00 r1 = 0x5
>     ;               break;
>          240:       05 00 01 00 00 00 00 00 goto +0x1 <foo+0x90>
>          241:       b7 01 00 00 13 00 00 00 r1 = 0x13
>          242:       18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0x0 ll
>                     0000000000000790:  R_BPF_64_64  ret_user
>          244:       7b 12 00 00 00 00 00 00 *(u64 *)(r2 + 0x0) = r1
>     ;       return 0;
>          245:       b4 00 00 00 00 00 00 00 w0 = 0x0
>          246:       95 00 00 00 00 00 00 00 exit
> 
> The jump table is
> 
>     242, 241, 241, 241, 241, 241, 241, 241,
>     241, 241, 241, 237, 241, 241, 241, 241,
>     241, 241, 241, 241, 241, 241, 241, 241,
>     241, 241, 241, 235, 241, 241, 241, 239
> 
> The check
> 
>     225:       25 01 0f 00 1f 00 00 00 if r1 > 0x1f goto +0xf <foo+0x88>
> 
> makes sure that the r1 register is always loaded from the jump table.
> This makes the instruction
> 
>     232:       05 00 08 00 00 00 00 00 goto +0x8 <foo+0x88>
> 
> unreachable.
> 
> Patch verifier to ignore such unreachable JA instructions.
> 
> Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> ---

This should be possible to handle on LLVM side, no need to deal with
it in the kernel.

[...]



  reply	other threads:[~2025-06-18 11:04 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-15  8:59 [RFC bpf-next 0/9] BPF indirect jumps Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 1/9] bpf: save the start of functions in bpf_prog_aux Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 2/9] bpf, x86: add new map type: instructions set Anton Protopopov
2025-06-18  0:57   ` Eduard Zingerman
2025-06-18  2:16     ` Alexei Starovoitov
2025-06-19 18:57       ` Anton Protopopov
2025-06-19 18:55     ` Anton Protopopov
2025-06-19 18:55       ` Eduard Zingerman
2025-06-15  8:59 ` [RFC bpf-next 3/9] selftests/bpf: add selftests for new insn_set map Anton Protopopov
2025-06-18 11:04   ` Eduard Zingerman
2025-06-18 15:16     ` Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 4/9] bpf, x86: allow indirect jumps to r8...r15 Anton Protopopov
2025-06-17 19:41   ` Alexei Starovoitov
2025-06-18 14:28     ` Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 5/9] bpf, x86: add support for indirect jumps Anton Protopopov
2025-06-18  3:06   ` Alexei Starovoitov
2025-06-19 19:57     ` Anton Protopopov
2025-06-19 19:58     ` Anton Protopopov
2025-06-18 11:03   ` Eduard Zingerman
2025-06-19 20:13     ` Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 6/9] bpf: workaround llvm behaviour with " Anton Protopopov
2025-06-18 11:04   ` Eduard Zingerman [this message]
2025-06-18 13:59     ` Alexei Starovoitov
2025-06-15  8:59 ` [RFC bpf-next 7/9] bpf: disasm: add support for BPF_JMP|BPF_JA|BPF_X Anton Protopopov
2025-06-15  8:59 ` [RFC bpf-next 8/9] libbpf: support llvm-generated indirect jumps Anton Protopopov
2025-06-18  3:22   ` Alexei Starovoitov
2025-06-18 15:08     ` Anton Protopopov
2025-07-07 23:45       ` Eduard Zingerman
2025-07-07 23:49         ` Alexei Starovoitov
2025-07-08  0:01           ` Eduard Zingerman
2025-07-08  0:12             ` Alexei Starovoitov
2025-07-08  0:18               ` Eduard Zingerman
2025-07-08  0:49                 ` Alexei Starovoitov
2025-07-08  0:51                   ` Eduard Zingerman
2025-07-08 20:59     ` Eduard Zingerman
2025-07-08 21:25       ` Alexei Starovoitov
2025-07-08 21:29         ` Eduard Zingerman
2025-07-09  5:33       ` Anton Protopopov
2025-07-09  5:58         ` Eduard Zingerman
2025-07-09  8:38           ` Eduard Zingerman
2025-07-10  5:11             ` Eduard Zingerman
2025-07-10  6:10               ` Anton Protopopov
2025-07-10  6:13                 ` Eduard Zingerman
2025-06-18 19:49   ` Eduard Zingerman
2025-06-27  2:28     ` Eduard Zingerman
2025-06-27 10:18       ` Anton Protopopov
2025-07-03 18:21         ` Eduard Zingerman
2025-07-03 19:03           ` Anton Protopopov
2025-07-07 19:07           ` Eduard Zingerman
2025-07-07 19:34             ` Anton Protopopov
2025-07-07 21:44             ` Yonghong Song
2025-07-08  5:58               ` Yonghong Song
2025-07-08  8:30             ` Eduard Zingerman
2025-07-08 10:42               ` Eduard Zingerman
2025-06-15  8:59 ` [RFC bpf-next 9/9] selftests/bpf: add selftests for " Anton Protopopov
2025-06-18  3:24   ` Alexei Starovoitov
2025-06-18 14:49     ` Anton Protopopov
2025-06-18 16:01       ` Alexei Starovoitov
2025-06-18 16:36         ` Anton Protopopov
2025-06-18 16:43           ` Alexei Starovoitov
2025-06-18 20:25             ` Anton Protopopov
2025-06-18 21:59               ` Alexei Starovoitov
2025-06-19  5:05                 ` Anton Protopopov

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=5be2b20d4190e6c2aed7386a350bccc3eaa79535.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=a.s.protopopov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=aspsk@isovalent.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=qmo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).