Re: [PATCH v5 09/11] perf symbol: Do not set binary type from symtab type

[Namhyung Kim <namhyung@kernel.org>]

On Tue, Oct 13, 2026 at 05:35:27PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] perf: guest kmodules misidentified as host system path DSOs
> --
> 
> commit 509bcd616550a20de7fa8d41090d38531f89cf60
> Author: Namhyung Kim <namhyung@kernel.org>
> 
> perf symbol: Do not set binary type from symtab type
> 
> The DSO binary type is used to access the binary data, while the symtab
> type is for the symbol table. This commit avoids setting the binary type
> from the symtab type when loading symbols, and instead updates the binary
> type only when opening the DSO.
> 
> > diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> > index 47241077ad260..1ca4cc5ec7db0 100644
> > --- a/tools/perf/util/dso.c
> > +++ b/tools/perf/util/dso.c
> > @@ -1491,9 +1491,10 @@ uint16_t dso__e_machine_endian(struct dso *dso, struct machine *machine, uint32_
> >  			       bool *is_big_endian)
> >  {
> >  	uint16_t e_machine = EM_NONE;
> > +	enum dso_binary_type dbt = dso__find_binary_type(dso);
> >  	int fd;
> >  
> > -	switch (dso__binary_type(dso)) {
> > +	switch (dbt) {
> 
> [Severity: High]
> Will this change cause guest kmodules to be misidentified as host system
> path DSOs?
> 
> By executing dso__find_binary_type() first, the code evaluates the priority
> list in dso__find_binary_type_locked(), which checks
> DSO_BINARY_TYPE__SYSTEM_PATH_DSO before falling back to dso__symtab_type(dso).
> 
> If the host filesystem happens to contain a module at the exact same absolute
> path as the guest kernel module (e.g., /lib/modules/x.y.z/...), the
> SYSTEM_PATH_DSO file check will succeed. This causes dso__find_binary_type()
> to return SYSTEM_PATH_DSO instead of DSO_BINARY_TYPE__GUEST_KMODULE.
> 
> Because dso__e_machine_endian() receives SYSTEM_PATH_DSO, it will fall
> through this fast-path switch, open the host file, and return the host's ELF
> machine architecture. Could this break cross-platform perf analysis (such as
> an x86_64 host analyzing an arm64 guest) by parsing the host's headers
> instead of the guest's?

To get a filename, it doesn't really matter if it's SYSTEM_PATH_DSO or
KMODULE (for host and guest).  Also I believe there's no good way to
retrive guest modules from the host other than symfs.

So I think this is fine for now.  Maybe we can work on improving guest
supports later.

Thanks,
Namhyung