Skip to content

Conversation

@auto-updater
Copy link
Contributor

@auto-updater auto-updater bot commented Oct 6, 2025

Changed files:

M	Ghidra/Processors/MIPS/data/languages/mips.sinc
M	Ghidra/Processors/MIPS/data/languages/mips16.sinc
M	Ghidra/Processors/eBPF/data/languages/eBPF.sinc

Commit details:

[Commit 1/7]
Hash: 575dfa7572af0c726fa2d69c512ab486315559e6
Date: 2025-09-10 12:42:00 +0000
Message: GP-5902: Fixed gotos

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 2/7]
Hash: a6e9ea090022e9a97dd8411e51caad64dc80e63c
Date: 2025-08-30 15:46:00 +0100
Message: mips: Don't use reserved keywords for names

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 3/7]
Hash: a72a68c4612c368c8f9790e586a6246273714ed1
Date: 2025-08-30 14:47:57 +0100
Message: mips: Use & ~1 rather than & -2

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 4/7]
Hash: 3c095be95654fb333ea4c22ede44f096b8c341e2
Date: 2025-08-19 20:51:02 +0100
Message: Fix LI failing to match in some cases

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 5/7]
Hash: 63919665ec3d07639c6cbe30285640b775c8f099
Date: 2025-08-02 01:42:30 +0100
Message: mips: Correctly handle 64-bit regs in INS and EXT 16e2 instructions

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 6/7]
Hash: b31997bba0bcc7502d47060022f8173e42077365
Date: 2025-08-02 01:08:43 +0100
Message: mips: Add mips16e2 instructions

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips.sinc
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 7/7]
Hash: 4f3f1059dc67d10db6a82c2c29c93d0d11504401
Date: 2025-04-01 22:24:44 +0200
Message: Add eBPF instruction CALLX for indirect calls
Details:
When clang encounters indirect calls in eBPF programs, it emits a call
instruction with a register parameter (`BPF_X`) instead of an immediate
value (`BPF_K`). This encoding (`BPF_JMP | BPF_CALL | BPF_X = 0x8d`) is
decoded by llvm-objdump as `callx`.

For example, here is a simple C program with an indirect call:

    extern void (*ptr_to_some_function)(void);
    void call_ptr_to_some_function(void) {
        ptr_to_some_function();
    }

Compiling and disassembling it gives with clang 14.0 (and LLVM 14.0):

    $ clang -O2 -target bpf -c indirect_call.c -o indirect_call.ebpf
    $ llvm-objdump -rd indirect_call.ebpf

    indirect_call.ebpf:  file format elf64-bpf

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
           0:  18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  r1 = 0 ll
                    0000000000000000:  R_BPF_64_64  ptr_to_some_function
           2:  79 11 00 00 00 00 00 00  r1 = *(u64 *)(r1 + 0)
           3:  8d 00 00 00 01 00 00 00  callx r1
           4:  95 00 00 00 00 00 00 00  exit

Contrary to usual eBPF instructions, `callx`'s register operand is
encoded in the immediate field. This encoding is actually specific to
LLVM (and clang). GCC used the destination register to store the target
register.

LLVM 19.1 was modified to use GCC's encoding:
https://github.com/llvm/llvm-project/pull/81546 ("BPF: Change callx insn
encoding"). For example, in an Alpine Linux 3.21 system:

    $ clang -target bpf --version
    Alpine clang version 19.1.4
    Target: bpf
    Thread model: posix
    InstalledDir: /usr/lib/llvm19/bin

    $ clang -O2 -target bpf -c indirect_call.c -o indirect_call.ebpf
    $ llvm-objdump -rd indirect_call.ebpf

    indirect_call.ebpf:  file format elf64-bpf

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
           0:  18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  r1 = 0x0 ll
                    0000000000000000:  R_BPF_64_64  ptr_to_some_function
           2:  79 11 00 00 00 00 00 00  r1 = *(u64 *)(r1 + 0x0)
           3:  8d 01 00 00 00 00 00 00  callx r1
           4:  95 00 00 00 00 00 00 00  exit

The instruction is now encoded `8d 01 00...`.

For reference, here are similar commands using GCC showing it is using
the same encoding (here, compiler option `-mxbpf` is required to enable
several features including indirect calls, cf.
https://gcc.gnu.org/onlinedocs/gcc-12.4.0/gcc/eBPF-Options.html ).

    $ bpf-gcc --version
    bpf-gcc (12-20220319-1ubuntu1+2) 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]

    $ bpf-gcc -O2 -c indirect_call.c -o indirect_call.ebpf -mxbpf
    $ bpf-objdump -mxbpf -rd indirect_call.ebpf

    indirect_call_gcc-12.ebpf:     file format elf64-bpfle

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
       0:  18 00 00 00 00 00 00 00   lddw %r0,0
       8:  00 00 00 00 00 00 00 00
          0: R_BPF_INSN_64  ptr_to_some_function
      10:  79 01 00 00 00 00 00 00   ldxdw %r1,[%r0+0]
      18:  8d 01 00 00 00 00 00 00   call %r1
      20:  95 00 00 00 00 00 00 00   exit

Add both `callx` instruction encodings to eBPF processor.

By the way, the eBPF Verifier used by Linux kernel currently forbids
indirect calls (it fails when `BPF_SRC(insn->code) != BPF_K`, in
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v6.14#n19141
). But other deployments of eBPF may already support this feature.

Files changed:
  M	Ghidra/Processors/eBPF/data/languages/eBPF.sinc

Changed files:

```
M	Ghidra/Processors/MIPS/data/languages/mips.sinc
M	Ghidra/Processors/MIPS/data/languages/mips16.sinc
M	Ghidra/Processors/eBPF/data/languages/eBPF.sinc
```

Commit details:

```
[Commit 1/7]
Hash: 575dfa7572af0c726fa2d69c512ab486315559e6
Date: 2025-09-10 12:42:00 +0000
Message: GP-5902: Fixed gotos

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 2/7]
Hash: a6e9ea090022e9a97dd8411e51caad64dc80e63c
Date: 2025-08-30 15:46:00 +0100
Message: mips: Don't use reserved keywords for names

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 3/7]
Hash: a72a68c4612c368c8f9790e586a6246273714ed1
Date: 2025-08-30 14:47:57 +0100
Message: mips: Use & ~1 rather than & -2

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 4/7]
Hash: 3c095be95654fb333ea4c22ede44f096b8c341e2
Date: 2025-08-19 20:51:02 +0100
Message: Fix LI failing to match in some cases

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 5/7]
Hash: 63919665ec3d07639c6cbe30285640b775c8f099
Date: 2025-08-02 01:42:30 +0100
Message: mips: Correctly handle 64-bit regs in INS and EXT 16e2 instructions

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 6/7]
Hash: b31997bba0bcc7502d47060022f8173e42077365
Date: 2025-08-02 01:08:43 +0100
Message: mips: Add mips16e2 instructions

Files changed:
  M	Ghidra/Processors/MIPS/data/languages/mips.sinc
  M	Ghidra/Processors/MIPS/data/languages/mips16.sinc

[Commit 7/7]
Hash: 4f3f1059dc67d10db6a82c2c29c93d0d11504401
Date: 2025-04-01 22:24:44 +0200
Message: Add eBPF instruction CALLX for indirect calls
Details:
When clang encounters indirect calls in eBPF programs, it emits a call
instruction with a register parameter (`BPF_X`) instead of an immediate
value (`BPF_K`). This encoding (`BPF_JMP | BPF_CALL | BPF_X = 0x8d`) is
decoded by llvm-objdump as `callx`.

For example, here is a simple C program with an indirect call:

    extern void (*ptr_to_some_function)(void);
    void call_ptr_to_some_function(void) {
        ptr_to_some_function();
    }

Compiling and disassembling it gives with clang 14.0 (and LLVM 14.0):

    $ clang -O2 -target bpf -c indirect_call.c -o indirect_call.ebpf
    $ llvm-objdump -rd indirect_call.ebpf

    indirect_call.ebpf:  file format elf64-bpf

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
           0:  18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  r1 = 0 ll
                    0000000000000000:  R_BPF_64_64  ptr_to_some_function
           2:  79 11 00 00 00 00 00 00  r1 = *(u64 *)(r1 + 0)
           3:  8d 00 00 00 01 00 00 00  callx r1
           4:  95 00 00 00 00 00 00 00  exit

Contrary to usual eBPF instructions, `callx`'s register operand is
encoded in the immediate field. This encoding is actually specific to
LLVM (and clang). GCC used the destination register to store the target
register.

LLVM 19.1 was modified to use GCC's encoding:
llvm/llvm-project#81546 ("BPF: Change callx insn
encoding"). For example, in an Alpine Linux 3.21 system:

    $ clang -target bpf --version
    Alpine clang version 19.1.4
    Target: bpf
    Thread model: posix
    InstalledDir: /usr/lib/llvm19/bin

    $ clang -O2 -target bpf -c indirect_call.c -o indirect_call.ebpf
    $ llvm-objdump -rd indirect_call.ebpf

    indirect_call.ebpf:  file format elf64-bpf

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
           0:  18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  r1 = 0x0 ll
                    0000000000000000:  R_BPF_64_64  ptr_to_some_function
           2:  79 11 00 00 00 00 00 00  r1 = *(u64 *)(r1 + 0x0)
           3:  8d 01 00 00 00 00 00 00  callx r1
           4:  95 00 00 00 00 00 00 00  exit

The instruction is now encoded `8d 01 00...`.

For reference, here are similar commands using GCC showing it is using
the same encoding (here, compiler option `-mxbpf` is required to enable
several features including indirect calls, cf.
https://gcc.gnu.org/onlinedocs/gcc-12.4.0/gcc/eBPF-Options.html ).

    $ bpf-gcc --version
    bpf-gcc (12-20220319-1ubuntu1+2) 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]

    $ bpf-gcc -O2 -c indirect_call.c -o indirect_call.ebpf -mxbpf
    $ bpf-objdump -mxbpf -rd indirect_call.ebpf

    indirect_call_gcc-12.ebpf:     file format elf64-bpfle

    Disassembly of section .text:

    0000000000000000 <call_ptr_to_some_function>:
       0:  18 00 00 00 00 00 00 00   lddw %r0,0
       8:  00 00 00 00 00 00 00 00
          0: R_BPF_INSN_64  ptr_to_some_function
      10:  79 01 00 00 00 00 00 00   ldxdw %r1,[%r0+0]
      18:  8d 01 00 00 00 00 00 00   call %r1
      20:  95 00 00 00 00 00 00 00   exit

Add both `callx` instruction encodings to eBPF processor.

By the way, the eBPF Verifier used by Linux kernel currently forbids
indirect calls (it fails when `BPF_SRC(insn->code) != BPF_K`, in
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v6.14#n19141
). But other deployments of eBPF may already support this feature.

Files changed:
  M	Ghidra/Processors/eBPF/data/languages/eBPF.sinc
```
@auto-updater auto-updater bot requested a review from ekilmer as a code owner October 6, 2025 00:25
@ekilmer ekilmer merged commit 97f7fd1 into master Oct 6, 2025
16 of 17 checks passed
@ekilmer ekilmer deleted the cron/update-ghidra-53cca61f8 branch October 6, 2025 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants