Re: [PATCH v1 6/7] perf annotate: Support BPF JIT disassembly via genelf

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The temporary ELF file for BPF JIT disassembly hardcodes the host architecture, breaking cross-platform analysis of perf.data files.
- [High] The temporary ELF file generated for BPF disassembly has a hardcoded Virtual Memory Address (VMA), causing objdump to output no instructions.
--

commit 13f48f3243b7525d8bdc81d7916d768a5bd50b37
Author: Ian Rogers <irogers@google.com>

perf annotate: Support BPF JIT disassembly via genelf

For in-memory BPF DSOs (DSO_BINARY_TYPE__BPF_PROG_INFO), write the
JITted instruction buffer to a temporary ELF file on disk using the
existing genelf framework (jit_write_elf). Reroute disassembly to
this temporary ELF file, allowing objdump and libasm to disassemble it
natively. Clean up the temporary file afterward.

> diff --git a/tools/perf/util/disasm.c b/tools/perf/util/disasm.c
> index 42af3603fdffd..8c78ef765787f 100644
> --- a/tools/perf/util/disasm.c
> +++ b/tools/perf/util/disasm.c
[ ... ]
> @@ -1540,6 +1543,41 @@ static int symbol__disassemble_objdump(const char *filename, struct symbol *sym,
>  	return err;
>  }
>  
> +#ifdef HAVE_LIBELF_SUPPORT
> +static int symbol__create_bpf_temp_elf(const char *filename, struct symbol *sym,
> +				       struct annotate_args *args,
> +				       char *tmp_elf, size_t tmp_elf_sz)
> +{
> +	struct map *map = args->ms->map;
> +	struct dso *dso = map__dso(map);
> +	u8 *code_buf = NULL;
> +	const u8 *buf;
> +	u64 buf_len;
> +	bool is_64bit;
> +	int tmp_fd;
> +	int err = -1;
> +
> +	buf = dso__read_symbol(dso, filename, map, sym, &code_buf, &buf_len, &is_64bit);
> +	if (!buf)
> +		return -1;
> +
> +	snprintf(tmp_elf, tmp_elf_sz, "/tmp/perf-bpf-XXXXXX");
> +	tmp_fd = mkstemp(tmp_elf);
> +	if (tmp_fd >= 0) {
> +		if (jit_write_elf(tmp_fd, map__rip_2objdump(map, sym->start),
> +				  sym->name, buf, buf_len,
> +				  NULL, 0, NULL, 0, 0) == 0) {
                  ^^^^^^^^^^^^^

[Severity: High]
Does this break cross-platform analysis of perf.data files?

When analyzing a perf.data file from a different architecture (e.g., recorded
on ARM64 but analyzed on an x86_64 host), jit_write_elf() generates the
temporary ELF file using host compile-time macros (GEN_ELF_ARCH).

Because the ELF header incorrectly claims the host's architecture instead of
the target's, disassemblers like objdump will decode the BPF JIT instructions
using the host's instruction set, producing garbage output.

[Severity: High]
Will objdump fail to output any instructions due to a mismatch in addresses?

Here, the actual symbol start address is passed to jit_write_elf() as
load_addr. However, jit_write_elf() ignores load_addr and hardcodes the
ELF .text section VMA and symbol address to GEN_ELF_TEXT_OFFSET (typically
0x40).

Later, symbol__disassemble_objdump() invokes objdump with --start-address
restricted to the actual symbol start address:

    err = asprintf(&command,
         "%s %s%s --start-address=0x%016" PRIx64
         " --stop-address=0x%016" PRIx64 ...
         map__rip_2objdump(map, sym->start),
         map__rip_2objdump(map, sym->end), ...)

Because the ELF file's contents reside at 0x40, objdump finds no instructions
within the requested start and stop address bounds, and fails the disassembly
process.

> +			err = 0;
> +		}
> +		close(tmp_fd);
> +		if (err)
> +			unlink(tmp_elf);
> +	}
> +	free(code_buf);
> +	return err;
> +}
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609051759.405027-1-irogers@google.com?part=6