linux-kernel - [PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Jun 2017 14:48:23 +0900
From:   Namhyung Kim <namhyung@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Jiri Olsa <jolsa@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, kernel-team@....com,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Andi Kleen <andi@...stfloor.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Wang Nan <wangnan0@...wei.com>
Subject: [PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly

When /proc/kallsyms is used for kernel address, addresses in module can
be changed when the module is reloaded.  So if one did perf record with
some module and then for some reason reload the module.  Then perf
report might see a different address for the module and the output can
show incorrect symbols.

For example, let a module XXX was loaded at 0xffffffff8a000000, the
/proc/kallsyms might show following:

  ...
  0xffffffff81234560 t last_symbol_in_vmlinux
  0xffffffff8a000000 t first_symbol_in_XXX
  ...

As kallsyms fixs up the symbol and map address by using next address,
the end address of last_symbol and kernel map would be start address of
XXX (0xffffffff8a000000).  And samples in 0xffffffff8a001234 can be
found in a map for XXX module.

But later, XXX was reloaded at 0xffffffff8a007000, slightly higher than
before.  Now reading /proc/kallsyms tells that the end address of last
symbol would be 0xfffffff8a007000 and so kernel map is same.  Now
samples in 0xffffffff8a001234 - formerly in the XXX module - would go to
the kernel map and show no symbols.

In this case, perf can know the address of map of XXX from mmap event in
perf.data so it can adjust kernel map address using the address of XXX
map.  To do that, replace map__fixup_end() by __map_groups__fixup_end().
This still have incorrect end address of last symbol in the kernel map
but it's ok since samples in that address wouldn't go to the kernel map
anyway.

Cc: Adrian Hunter <adrian.hunter@...el.com>
Cc: Wang Nan <wangnan0@...wei.com>
Signed-off-by: Namhyung Kim <namhyung@...nel.org>
---
 tools/perf/util/symbol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 74078ba595b3..ce79a51f25bf 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1832,7 +1832,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct map *map)
 		dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
 		dso__set_long_name(dso, DSO__NAME_KALLSYMS, false);
 		map__fixup_start(map);
-		map__fixup_end(map);
+		__map_groups__fixup_end(map->groups, map->type);
 	}

 	return err;
@@ -1880,7 +1880,7 @@ static int dso__load_guest_kernel_sym(struct dso *dso, struct map *map)
 		machine__mmap_name(machine, path, sizeof(path));
 		dso__set_long_name(dso, strdup(path), true);
 		map__fixup_start(map);
-		map__fixup_end(map);
+		__map_groups__fixup_end(map->groups, map->type);
 	}

 	return err;
-- 
2.13.1