perf symbols: Handle /proc/sys/kernel/kptr_restrict

Commit-ID:  ec80fde746e3ccf93895d25ae1a7071c9af52585
Gitweb:     http://git.kernel.org/tip/ec80fde746e3ccf93895d25ae1a7071c9af52585
Author:     Arnaldo Carvalho de Melo <[email protected]>
AuthorDate: Thu, 26 May 2011 09:53:51 -0300
Committer:  Arnaldo Carvalho de Melo <[email protected]>
CommitDate: Thu, 26 May 2011 11:15:25 -0300

perf symbols: Handle /proc/sys/kernel/kptr_restrict

Perf uses /proc/modules to figure out where kernel modules are loaded.

With the advent of kptr_restrict, non root users get zeroes for all module start addresses.

So check if kptr_restrict is non zero and don't generate the syntethic PERF_RECORD_MMAP events for them.

Warn the user about it in perf record and in perf report.

In perf report the reference relocation symbol being zero means that kptr_restrict was set, thus /proc/kallsyms has only zeroed addresses, so don't use it to fixup symbol addresses when using a valid kallsyms (in the buildid cache) or vmlinux (in the vmlinux path) build-id located automatically or specified by the user.

Provide an explanation about it in 'perf report' if kernel samples were taken, checking if a suitable vmlinux or kallsyms was found/specified.

Restricted /proc/kallsyms don't go to the buildid cache anymore.

Example:

[acme@emilia ~]$ perf record -F 100000 sleep 1

WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check /proc/sys/kernel/kptr_restrict.

Samples in kernel functions may not be resolved if a suitable vmlinux file is not found in the buildid cache or in the vmlinux path.

Samples in kernel modules won't be resolved at all.

If some relocation was applied (e.g. kexec) symbols may be misresolved even with a suitable vmlinux or kallsyms file.

[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.005 MB perf.data (~231 samples) ] [acme@emilia ~]$

[acme@emilia ~]$ perf report --stdio
Kernel address maps (/proc/{kallsyms,modules}) were restricted, check /proc/sys/kernel/kptr_restrict before running 'perf record'.

If some relocation was applied (e.g. kexec) symbols may be misresolved.

Samples in kernel modules can't be resolved as well.

# Events: 13 cycles
#
# Overhead Command Shared Object Symbol

 # ........  .......  .................  .....................
 #
    20.24%    sleep  [kernel.kallsyms]  [k] page_fault
    20.04%    sleep  [kernel.kallsyms]  [k] filemap_fault
    19.78%    sleep  [kernel.kallsyms]  [k] __lru_cache_add
    19.69%    sleep  ld-2.12.so         [.] memcpy
    14.71%    sleep  [kernel.kallsyms]  [k] dput
     4.70%    sleep  [kernel.kallsyms]  [k] flush_signal_handlers
     0.73%    sleep  [kernel.kallsyms]  [k] perf_event_comm
     0.11%    sleep  [kernel.kallsyms]  [k] native_write_msr_safe

#
# (For a higher level overview, try: perf report --sort comm,dso) #
[acme@emilia ~]$

This is because it found a suitable vmlinux (build-id checked) in /lib/modules/2.6.39-rc7+/build/vmlinux (use -v in perf report to see the long file name).

If we remove that file from the vmlinux path:

 [root@emilia ~]# mv /lib/modules/2.6.39-rc7+/build/vmlinux \
		     /lib/modules/2.6.39-rc7+/build/vmlinux.OFF

[acme@emilia ~]$ perf report --stdio
[kernel.kallsyms] with build id 57298cdbe0131f6871667ec0eaab4804dcf6f562 not found, continuing without symbols

Kernel address maps (/proc/{kallsyms,modules}) were restricted, check /proc/sys/kernel/kptr_restrict before running 'perf record'.

As no suitable kallsyms nor vmlinux was found, kernel samples can't be resolved.

Samples in kernel modules can't be resolved as well.

# Events: 13 cycles
#

 # Overhead  Command      Shared Object  Symbol
 # ........  .......  .................  ......
 #
    80.31%    sleep  [kernel.kallsyms]  [k] 0xffffffff8103425a
    19.69%    sleep  ld-2.12.so         [.] memcpy

#
# (For a higher level overview, try: perf report --sort comm,dso) #
[acme@emilia ~]$

---
 tools/perf/builtin-record.c |   13 +++++++++++
 tools/perf/builtin-report.c |   26 +++++++++++++++++++++++
 tools/perf/util/event.c     |   15 ++++++++++--
 tools/perf/util/header.c    |    8 +++++-
 tools/perf/util/symbol.c    |   48 +++++++++++++++++++++++++++++++++++++++++++
 tools/perf/util/symbol.h    |    3 +-
 6 files changed, 107 insertions(+), 6 deletions(-)

index 0974f95..2ca107f 100644
@@ -823,6 +823,19 @@ int cmd_record(int argc, const char **argv, const char *prefix __used)
 
 	symbol__init();
 
+	if (symbol_conf.kptr_restrict)
+		pr_warning("WARNING: Kernel address maps "
+			   "(/proc/{kallsyms,modules}) are restricted, "
+			   "check /proc/sys/kernel/kptr_restrict.\n\n"
+			   "Samples in kernel functions may not be resolved "
+			   "if a suitable vmlinux file is not found in the "
+			   "buildid cache or in the vmlinux path.\n\n"
+			   "Samples in kernel modules won't be resolved "
+			   "at all.\n\n"
+			   "If some relocation was applied (e.g. kexec) "
+			   "symbols may be misresolved even with a suitable "
+			   "vmlinux or kallsyms file.\n\n");
+
 	if (no_buildid_cache || no_buildid)
 		disable_buildid_cache();
 

index 498c6f7..99156c3 100644
@@ -116,6 +116,9 @@ static int process_sample_event(union perf_event *event,
 	if (al.filtered || (hide_unresolved && al.sym == NULL))
 		return 0;
 
+	if (al.map != NULL)
+		al.map->dso->hit = 1;
+
 	if (perf_session__add_hist_entry(session, &al, sample, evsel)) {
 		pr_debug("problem incrementing symbol period, skipping event\n");
 		return -1;

@@ -249,6 +252,8 @@ static int __cmd_report(void)
 	u64 nr_samples;
 	struct perf_session *session;
 	struct perf_evsel *pos;
+	struct map *kernel_map;
+	struct kmap *kernel_kmap;
 	const char *help = "For a higher level overview, try: perf report --sort comm,dso";
 
 	signal(SIGINT, sig_handler);

@@ -268,6 +273,27 @@ static int __cmd_report(void)
 	if (ret)
 		goto out_delete;
 
+	kernel_map = session->host_machine.vmlinux_maps[MAP__FUNCTION];
+	kernel_kmap = map__kmap(kernel_map);
+	if (kernel_map == NULL ||
+	    (kernel_map->dso->hit &&
+	     (kernel_kmap->ref_reloc_sym == NULL ||
+	      kernel_kmap->ref_reloc_sym->addr == 0))) {
+		const struct dso *kdso = kernel_map->dso;
+
+		ui__warning("Kernel address maps "
+			    "(/proc/{kallsyms,modules}) were restricted, "
+			    "check /proc/sys/kernel/kptr_restrict before "
+			    "running 'perf record'.\n\n%s\n\n"
+			    "Samples in kernel modules can't be resolved "
+			    "as well.\n\n",
+			    RB_EMPTY_ROOT(&kdso->symbols[MAP__FUNCTION]) ?
+			    "As no suitable kallsyms nor vmlinux was found, "
+			    "kernel samples can't be resolved." :
+			    "If some relocation was applied (e.g. kexec) "
+			    "symbols may be misresolved.");
+	}
+
 	if (dump_trace) {
 		perf_session__fprintf_nr_events(session, stdout);
 		goto out_delete;

index 6635fcd..0fe9adf 100644
@@ -553,9 +553,18 @@ static int perf_event__process_kernel_mmap(union perf_event *event,
 			goto out_problem;
 
 		perf_event__set_kernel_mmap_len(event, machine->vmlinux_maps);
-		perf_session__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps,
-							 symbol_name,
-							 event->mmap.pgoff);
+
+		/*
+		 * Avoid using a zero address (kptr_restrict) for the ref reloc
+		 * symbol. Effectively having zero here means that at record
+		 * time /proc/sys/kernel/kptr_restrict was non zero.
+		 */
+		if (event->mmap.pgoff != 0) {
+			perf_session__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps,
+								 symbol_name,
+								 event->mmap.pgoff);
+		}
+
 		if (machine__is_default_guest(machine)) {
 			/*
 			 * preload dso of guest kernel and modules

index 0717beb..afb0849 100644
@@ -193,9 +193,13 @@ int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
 	     *linkname = malloc(size), *targetname;
 	int len, err = -1;
 
-	if (is_kallsyms)
+	if (is_kallsyms) {
+		if (symbol_conf.kptr_restrict) {
+			pr_debug("Not caching a kptr_restrict'ed /proc/kallsyms\n");
+			return 0;
+		}
 		realname = (char *)name;
-	else
+	} else
 		realname = realpath(name, NULL);
 
 	if (realname == NULL || filename == NULL || linkname == NULL)

index 242de01..325ee36 100644
@@ -75,7 +75,8 @@ struct symbol_conf {
 			use_callchain,
 			exclude_other,
 			show_cpu_utilization,
-			initialized;
+			initialized,
+			kptr_restrict;
 	const char	*vmlinux_name,
 			*kallsyms_name,
 			*source_prefix,

Ok, things are much better now with kptr_restrict turned on - but i still see a few rough edges in practice.

For example 'perf top' says:

aldebaran:~/linux> perf top
[kernel.kallsyms] with build id 122214021a666675f6e5ff97d70a85ce7139c0e7 not found, continuing without symbols The (null) file can't be used

Now we've confused the user, havent we? :-)

Also, if i run 'perf top' with the proper vmlinux in the cwd, i do not get any warning messages - despite both module symbols not being available and potetial relocations not being considered.

Secondly, even though i have the proper 'vmlinux' in cwd, i get half a page long warnings on perf record warning me about the vmlinux:

WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check /proc/sys/kernel/kptr_restrict.

Samples in kernel functions may not be resolved if a suitable vmlinux file is not found in the buildid cache or in the vmlinux path.

...

But a vmlinux file *is* in the cwd.

One detail i noticed in the patch:

	if (symbol_conf.kptr_restrict) {
		pr_warning(

	}

Em Thu, May 26, 2011 at 09:39:46PM +0200, Ingo Molnar escreveu:

please wait a bit more, I completely forgot testing 'perf top' :-\

Right, it has to provide similar warning.

But it would reflow, no?

Em Thu, May 26, 2011 at 09:39:46PM +0200, Ingo Molnar escreveu:

Well, there was no assumption that 'perf report' would run on the same directory as 'perf record', the user may have moved to a different directory or transferred the perf.data file to a different machine.

Also it would have to check that the vmlinux on the path is suitable (that build-id matches), currently it does that just at 'perf report' time, that is when it will need to use it. At record time we just collect the build-ids.

With that in mind, how do you think it should be phrased?

- Arnaldo

Em Thu, May 26, 2011 at 09:39:46PM +0200, Ingo Molnar escreveu:

The ones that do:

# echo -1 > /proc/sys/kernel/perf_event_paranoid

Right?

Trying that, not usually something I do :)

- Arnaldo

I think the biggest problem is that it is yelling at us even when i'm root - and root can access all the pointer values just fine:

 # id
 uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

 # perf report --stdio
 No kallsyms or vmlinux with build-id 122214021a666675f6e5ff97d70a85ce7139c0e7 was found
 [kernel.kallsyms] with build id 122214021a666675f6e5ff97d70a85ce7139c0e7 not found, continuing without s
 Kernel address maps (/proc/{kallsyms,modules}) were restricted, check /proc/sys/kernel/kptr_restrict bef

 # tail -1 /proc/kallsyms 
 ffffffffff600d00 D __vvar_vsyscall_gtod_data

Thanks,

Ingo

Not on all terminals. For example my terminal will just cut anything beyond the col limit:

 # perf report --stdio
 No kallsyms or vmlinux with build-id 122214021a666675f6e5ff97d70a85ce7139c0e7 was found
 [kernel.kallsyms] with build id 122214021a666675f6e5ff97d70a85ce7139c0e7 not found, continuing without s
 Kernel address maps (/proc/{kallsyms,modules}) were restricted, check /proc/sys/kernel/kptr_restrict bef

So we generally want to generate error messages to look good on col80
- it should not be hard here, right?

Thanks,

Ingo

Or the ones that do:

aldebaran:~> ./loop_yield &
[1] 7557
aldebaran:~>
aldebaran:~> perf top -p 7557
[kernel.kallsyms] with build id 44d9a989eabbd79e486bc079d6b743d397c204e0 not found, continuing without symbols The (null) file can't be used

Also, we might eventually make perf events more widely available by default, so even default 'perf top' might do something useful for unprivileged users.

i run all my perf workflow unprivileged - as root you can always typo catastrophically :-)

Thanks,

Ingo

Instead of looking at the kptr_restrict file, please just look at the addresses in the kallsyms file, and if they are all zero, you know that it's not a usable kallsyms file (and you can pretty much assume that it's due to kptr_restrict).

So I think the whole symbol__read_kptr_restrict() thing is just pointless. Don't do it.

Linus

Em Fri, May 27, 2011 at 08:46:42AM -0700, Linus Torvalds escreveu:

I thought about that, ended up using the file not to rely on the values on kallsyms, too much future proofing, I guess.

BTW, the problem reported by Ingo above (yelling even for root) is not a bug, he ran 'perf record' as non root with kptr_restrict set and then ran 'perf report' as root.

- Arnaldo