From: Craig Gallek <kraigatgoog@gmail.com>
To: Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <brouer@redhat.com>,
"David S . Miller" <davem@davemloft.net>
Cc: Chonggang Li <chonggangli@google.com>, netdev@vger.kernel.org
Subject: [PATCH net-next v2 1/2] libbpf: parse maps sections of varying size
Date: Mon, 2 Oct 2017 12:41:28 -0400 [thread overview]
Message-ID: <20171002164129.47986-2-kraigatgoog@gmail.com> (raw)
In-Reply-To: <20171002164129.47986-1-kraigatgoog@gmail.com>
From: Craig Gallek <kraig@google.com>
This library previously assumed a fixed-size map options structure.
Any new options were ignored. In order to allow the options structure
to grow and to support parsing older programs, this patch updates
the maps section parsing to handle varying sizes.
Object files with maps sections smaller than expected will have the new
fields initialized to zero. Object files which have larger than expected
maps sections will be rejected unless all of the unrecognized data is zero.
This change still assumes that each map definition in the maps section
is the same size.
Signed-off-by: Craig Gallek <kraig@google.com>
---
tools/lib/bpf/libbpf.c | 54 ++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4f402dcdf372..28b300868ad7 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -580,7 +580,7 @@ bpf_object__init_kversion(struct bpf_object *obj,
}
static int
-bpf_object__validate_maps(struct bpf_object *obj)
+bpf_object__validate_maps(struct bpf_object *obj, int map_def_sz)
{
int i;
@@ -595,9 +595,11 @@ bpf_object__validate_maps(struct bpf_object *obj)
const struct bpf_map *a = &obj->maps[i - 1];
const struct bpf_map *b = &obj->maps[i];
- if (b->offset - a->offset < sizeof(struct bpf_map_def)) {
- pr_warning("corrupted map section in %s: map \"%s\" too small\n",
- obj->path, a->name);
+ if (b->offset - a->offset < map_def_sz) {
+ pr_warning("corrupted map section in %s: map \"%s\" too small "
+ "(%zd vs %d)\n",
+ obj->path, a->name, b->offset - a->offset,
+ map_def_sz);
return -EINVAL;
}
}
@@ -615,7 +617,7 @@ static int compare_bpf_map(const void *_a, const void *_b)
static int
bpf_object__init_maps(struct bpf_object *obj)
{
- int i, map_idx, nr_maps = 0;
+ int i, map_idx, map_def_sz, nr_maps = 0;
Elf_Scn *scn;
Elf_Data *data;
Elf_Data *symbols = obj->efile.symbols;
@@ -658,6 +660,15 @@ bpf_object__init_maps(struct bpf_object *obj)
if (!nr_maps)
return 0;
+ /* Assume equally sized map definitions */
+ map_def_sz = data->d_size / nr_maps;
+ if (!data->d_size || (data->d_size % nr_maps) != 0) {
+ pr_warning("unable to determine map definition size "
+ "section %s, %d maps in %zd bytes\n",
+ obj->path, nr_maps, data->d_size);
+ return -EINVAL;
+ }
+
obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
if (!obj->maps) {
pr_warning("alloc maps for object failed\n");
@@ -690,7 +701,7 @@ bpf_object__init_maps(struct bpf_object *obj)
obj->efile.strtabidx,
sym.st_name);
obj->maps[map_idx].offset = sym.st_value;
- if (sym.st_value + sizeof(struct bpf_map_def) > data->d_size) {
+ if (sym.st_value + map_def_sz > data->d_size) {
pr_warning("corrupted maps section in %s: last map \"%s\" too small\n",
obj->path, map_name);
return -EINVAL;
@@ -704,12 +715,39 @@ bpf_object__init_maps(struct bpf_object *obj)
pr_debug("map %d is \"%s\"\n", map_idx,
obj->maps[map_idx].name);
def = (struct bpf_map_def *)(data->d_buf + sym.st_value);
- obj->maps[map_idx].def = *def;
+ /*
+ * If the definition of the map in the object file fits in
+ * bpf_map_def, copy it. Any extra fields in our version
+ * of bpf_map_def will default to zero as a result of the
+ * calloc above.
+ */
+ if (map_def_sz <= sizeof(struct bpf_map_def)) {
+ memcpy(&obj->maps[map_idx].def, def, map_def_sz);
+ } else {
+ /*
+ * Here the map structure being read is bigger than what
+ * we expect, truncate if the excess bits are all zero.
+ * If they are not zero, reject this map as
+ * incompatible.
+ */
+ char *b;
+ for (b = ((char *)def) + sizeof(struct bpf_map_def);
+ b < ((char *)def) + map_def_sz; b++) {
+ if (*b != 0) {
+ pr_warning("maps section in %s: \"%s\" "
+ "has unrecognized, non-zero "
+ "options\n",
+ obj->path, map_name);
+ return -EINVAL;
+ }
+ }
+ obj->maps[map_idx].def = *def;
+ }
map_idx++;
}
qsort(obj->maps, obj->nr_maps, sizeof(obj->maps[0]), compare_bpf_map);
- return bpf_object__validate_maps(obj);
+ return bpf_object__validate_maps(obj, map_def_sz);
}
static int bpf_object__elf_collect(struct bpf_object *obj)
--
2.14.2.822.g60be5d43e6-goog
next prev parent reply other threads:[~2017-10-02 16:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 16:41 [PATCH net-next v2 0/2] libbpf: support more map options Craig Gallek
2017-10-02 16:41 ` Craig Gallek [this message]
2017-10-02 23:07 ` [PATCH net-next v2 1/2] libbpf: parse maps sections of varying size Alexei Starovoitov
2017-10-03 14:39 ` Daniel Borkmann
2017-10-04 13:59 ` Craig Gallek
2017-10-04 19:27 ` Daniel Borkmann
2017-10-04 19:54 ` Alexei Starovoitov
2017-10-03 14:03 ` Jesper Dangaard Brouer
2017-10-04 13:58 ` Craig Gallek
2017-10-04 14:12 ` David Laight
2017-10-03 14:11 ` Jesper Dangaard Brouer
2017-10-04 13:58 ` Craig Gallek
2017-10-04 13:58 ` Craig Gallek
2017-10-02 16:41 ` [PATCH net-next v2 2/2] libbpf: use map_flags when creating maps Craig Gallek
2017-10-04 4:26 ` [PATCH net-next v2 0/2] libbpf: support more map options David Miller
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=20171002164129.47986-2-kraigatgoog@gmail.com \
--to=kraigatgoog@gmail.com \
--cc=ast@fb.com \
--cc=brouer@redhat.com \
--cc=chonggangli@google.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).