From: Wang Nan <wangnan0@huawei.com>
To: <namhyung@kernel.org>, <acme@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <pi3orama@163.com>,
<lizefen@huawei.com>, Wang Nan <wangnan0@huawei.com>
Subject: [PATCH] tools lib bpf: Fetch map names from correct strtab
Date: Mon, 30 Nov 2015 10:39:10 +0000 [thread overview]
Message-ID: <1448879950-226288-1-git-send-email-wangnan0@huawei.com> (raw)
In-Reply-To: <3ABFD871-09F8-4C21-9EF7-06FCECA2E106@gmail.com>
Namhyung Kim pointed out a potential problem in original code that it
fetches names of maps from section header string table, which is used
to store section names.
Original code doesn't cause error because of a LLVM behavior that, it
combines shstrtab into strtab. For example:
$ echo 'int func() {return 0;}' | x86_64-oe-linux-clang -x c -o temp.o -c -
$ readelf -h ./temp.o
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
...
Section header string table index: 1
$ readelf -S ./temp.o
There are 10 section headers, starting at offset 0x288:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .strtab STRTAB 0000000000000000 00000230
0000000000000051 0000000000000000 0 0 1
...
$ readelf -p .strtab ./temp.o
String dump of section '.strtab':
[ 1] .text
[ 7] .comment
[ 10] .bss
[ 15] .note.GNU-stack
[ 25] .rela.eh_frame
[ 34] func
[ 39] .strtab
[ 41] .symtab
[ 49] .data
[ 4f] -
$ readelf -p .shstrtab ./temp.o
readelf: Warning: Section '.shstrtab' was not dumped because it does not exist!
Where, 'section header string table index' points to '.strtab', and
symbol names are also stored there.
However, in case of gcc:
$ echo 'int func() {return 0;}' | gcc -x c -o temp.o -c -
$ readelf -p .shstrtab ./temp.o
String dump of section '.shstrtab':
[ 1] .symtab
[ 9] .strtab
[ 11] .shstrtab
[ 1b] .text
[ 21] .data
[ 27] .bss
[ 2c] .comment
[ 35] .note.GNU-stack
[ 45] .rela.eh_frame
$ readelf -p .strtab ./temp.o
String dump of section '.strtab':
[ 1] func
They are separated sections.
Although original code doesn't cause error, we'd better use canonical
method for fetching symbol names to avoid potential behavior changing.
This patch learns from readelf's code, fetches string from sh_link
of .symbol section.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/lib/bpf/libbpf.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 16485ab..8334a5a 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -195,6 +195,7 @@ struct bpf_object {
Elf *elf;
GElf_Ehdr ehdr;
Elf_Data *symbols;
+ size_t strtabidx;
struct {
GElf_Shdr shdr;
Elf_Data *data;
@@ -547,7 +548,7 @@ bpf_object__init_maps_name(struct bpf_object *obj, int maps_shndx)
continue;
map_name = elf_strptr(obj->efile.elf,
- obj->efile.ehdr.e_shstrndx,
+ obj->efile.strtabidx,
sym.st_name);
map_idx = sym.st_value / sizeof(struct bpf_map_def);
if (map_idx >= obj->nr_maps) {
@@ -630,8 +631,10 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
pr_warning("bpf: multiple SYMTAB in %s\n",
obj->path);
err = -LIBBPF_ERRNO__FORMAT;
- } else
+ } else {
obj->efile.symbols = data;
+ obj->efile.strtabidx = sh.sh_link;
+ }
} else if ((sh.sh_type == SHT_PROGBITS) &&
(sh.sh_flags & SHF_EXECINSTR) &&
(data->d_size > 0)) {
@@ -667,6 +670,10 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
goto out;
}
+ if (!obj->efile.strtabidx || obj->efile.strtabidx >= idx) {
+ pr_warning("Corrupted ELF file: index of strtab invalid\n");
+ return LIBBPF_ERRNO__FORMAT;
+ }
if (maps_shndx >= 0)
err = bpf_object__init_maps_name(obj, maps_shndx);
out:
--
1.8.3.4
next prev parent reply other threads:[~2015-11-30 10:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 8:47 [PATCH v2 00/13] perf tools: BPF related update Wang Nan
2015-11-27 8:47 ` [PATCH v2 01/13] bpf tools: Collect map definition in bpf_object Wang Nan
2015-11-29 7:57 ` [tip:perf/core] tools lib bpf: " tip-bot for Wang Nan
2015-11-27 8:47 ` [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file Wang Nan
2015-11-29 7:57 ` [tip:perf/core] tools lib bpf: " tip-bot for Wang Nan
2015-11-29 16:14 ` [PATCH v2 02/13] bpf tools: " Namhyung Kim
2015-11-30 5:00 ` Wangnan (F)
2015-11-30 8:51 ` Namhyung Kim
2015-11-30 9:27 ` Wangnan (F)
2015-11-30 9:43 ` Namhyung Kim
2015-11-30 9:48 ` Wangnan (F)
2015-11-30 10:39 ` Wang Nan [this message]
2015-11-30 11:19 ` [PATCH] tools lib bpf: Fetch map names from correct strtab Namhyung Kim
2015-11-27 8:47 ` [PATCH v2 03/13] perf tools: Rename bpf config to program config Wang Nan
2015-11-29 7:58 ` [tip:perf/core] perf bpf: " tip-bot for Wang Nan
2015-11-27 8:47 ` [PATCH v2 04/13] perf tools: Add API to config maps in bpf object Wang Nan
2015-11-28 1:10 ` RFC " Arnaldo Carvalho de Melo
2015-11-28 1:20 ` Wangnan (F)
2015-11-28 1:21 ` Wangnan (F)
2015-11-29 16:21 ` Namhyung Kim
2015-11-27 8:47 ` [PATCH v2 05/13] perf tools: Enable BPF object configure syntax Wang Nan
2015-11-27 8:47 ` [PATCH v2 06/13] perf record: Apply config to BPF objects before recording Wang Nan
2015-11-27 8:47 ` [PATCH v2 07/13] perf tools: Support perf event alias name Wang Nan
2015-11-27 8:47 ` [PATCH v2 08/13] perf tools: Enable passing event to BPF object Wang Nan
2015-11-27 8:47 ` [PATCH v2 09/13] perf tools: Support setting different slots in a BPF map separately Wang Nan
2015-11-27 8:47 ` [PATCH v2 10/13] perf tools: Enable indices setting syntax for BPF maps Wang Nan
2015-11-27 8:47 ` [PATCH v2 11/13] perf tools: Introduce bpf-output event Wang Nan
2015-11-27 8:47 ` [PATCH v2 12/13] perf data: Add u32_hex data type Wang Nan
2015-11-27 8:47 ` [PATCH v2 13/13] perf data: Support converting data from bpf_perf_event_output() Wang Nan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448879950-226288-1-git-send-email-wangnan0@huawei.com \
--to=wangnan0@huawei.com \
--cc=acme@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefen@huawei.com \
--cc=namhyung@kernel.org \
--cc=pi3orama@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®