BPF Archive on lore.kernel.org
 help / color / Atom feed
* [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions
@ 2019-12-02 12:37 Jesper Dangaard Brouer
  2019-12-02 13:02 ` Toke Høiland-Jørgensen
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jesper Dangaard Brouer @ 2019-12-02 12:37 UTC (permalink / raw)
  To: bpf
  Cc: jakub.kicinski, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
	danieltimlee, Alexei Starovoitov

In the days of using bpf_load.c the order in which the 'maps' sections
were defines in BPF side (*_kern.c) file, were used by userspace side
to identify the map via using the map order as an index. In effect the
order-index is created based on the order the maps sections are stored
in the ELF-object file, by the LLVM compiler.

This have also carried over in libbpf via API bpf_map__next(NULL, obj)
to extract maps in the order libbpf parsed the ELF-object file.

When BTF based maps were introduced a new section type ".maps" were
created. I found that the LLVM compiler doesn't create the ".maps"
sections in the order they are defined in the C-file. The order in the
ELF file is based on the order the map pointer is referenced in the code.

This combination of changes lead to xdp_rxq_info mixing up the map
file-descriptors in userspace, resulting in very broken behaviour, but
without warning the user.

This patch fix issue by instead using bpf_object__find_map_by_name()
to find maps via their names. (Note, this is the ELF name, which can
be longer than the name the kernel retains).

Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf")
Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
 samples/bpf/xdp_rxq_info_user.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/samples/bpf/xdp_rxq_info_user.c b/samples/bpf/xdp_rxq_info_user.c
index 51e0d810e070..8fc3ad01de72 100644
--- a/samples/bpf/xdp_rxq_info_user.c
+++ b/samples/bpf/xdp_rxq_info_user.c
@@ -489,9 +489,9 @@ int main(int argc, char **argv)
 	if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
 		return EXIT_FAIL;
 
-	map = bpf_map__next(NULL, obj);
-	stats_global_map = bpf_map__next(map, obj);
-	rx_queue_index_map = bpf_map__next(stats_global_map, obj);
+	map =  bpf_object__find_map_by_name(obj, "config_map");
+	stats_global_map = bpf_object__find_map_by_name(obj, "stats_global_map");
+	rx_queue_index_map = bpf_object__find_map_by_name(obj, "rx_queue_index_map");
 	if (!map || !stats_global_map || !rx_queue_index_map) {
 		printf("finding a map in obj file failed\n");
 		return EXIT_FAIL;


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions
  2019-12-02 12:37 [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions Jesper Dangaard Brouer
@ 2019-12-02 13:02 ` Toke Høiland-Jørgensen
  2019-12-02 17:35 ` Andrii Nakryiko
  2019-12-05  1:54 ` Alexei Starovoitov
  2 siblings, 0 replies; 4+ messages in thread
From: Toke Høiland-Jørgensen @ 2019-12-02 13:02 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, bpf
  Cc: jakub.kicinski, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
	danieltimlee, Alexei Starovoitov

Jesper Dangaard Brouer <brouer@redhat.com> writes:

> In the days of using bpf_load.c the order in which the 'maps' sections
> were defines in BPF side (*_kern.c) file, were used by userspace side
> to identify the map via using the map order as an index. In effect the
> order-index is created based on the order the maps sections are stored
> in the ELF-object file, by the LLVM compiler.
>
> This have also carried over in libbpf via API bpf_map__next(NULL, obj)
> to extract maps in the order libbpf parsed the ELF-object file.
>
> When BTF based maps were introduced a new section type ".maps" were
> created. I found that the LLVM compiler doesn't create the ".maps"
> sections in the order they are defined in the C-file. The order in the
> ELF file is based on the order the map pointer is referenced in the code.
>
> This combination of changes lead to xdp_rxq_info mixing up the map
> file-descriptors in userspace, resulting in very broken behaviour, but
> without warning the user.
>
> This patch fix issue by instead using bpf_object__find_map_by_name()
> to find maps via their names. (Note, this is the ELF name, which can
> be longer than the name the kernel retains).
>
> Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf")
> Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions
  2019-12-02 12:37 [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions Jesper Dangaard Brouer
  2019-12-02 13:02 ` Toke Høiland-Jørgensen
@ 2019-12-02 17:35 ` Andrii Nakryiko
  2019-12-05  1:54 ` Alexei Starovoitov
  2 siblings, 0 replies; 4+ messages in thread
From: Andrii Nakryiko @ 2019-12-02 17:35 UTC (permalink / raw)
  To: Jesper Dangaard Brouer
  Cc: bpf, Jakub Kicinski, Networking, Daniel Borkmann, Daniel T. Lee,
	Alexei Starovoitov

On Mon, Dec 2, 2019 at 4:37 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>
> In the days of using bpf_load.c the order in which the 'maps' sections
> were defines in BPF side (*_kern.c) file, were used by userspace side
> to identify the map via using the map order as an index. In effect the
> order-index is created based on the order the maps sections are stored
> in the ELF-object file, by the LLVM compiler.
>
> This have also carried over in libbpf via API bpf_map__next(NULL, obj)
> to extract maps in the order libbpf parsed the ELF-object file.
>
> When BTF based maps were introduced a new section type ".maps" were
> created. I found that the LLVM compiler doesn't create the ".maps"
> sections in the order they are defined in the C-file. The order in the
> ELF file is based on the order the map pointer is referenced in the code.
>
> This combination of changes lead to xdp_rxq_info mixing up the map
> file-descriptors in userspace, resulting in very broken behaviour, but
> without warning the user.
>
> This patch fix issue by instead using bpf_object__find_map_by_name()
> to find maps via their names. (Note, this is the ELF name, which can
> be longer than the name the kernel retains).
>
> Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf")
> Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
>  samples/bpf/xdp_rxq_info_user.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/samples/bpf/xdp_rxq_info_user.c b/samples/bpf/xdp_rxq_info_user.c
> index 51e0d810e070..8fc3ad01de72 100644
> --- a/samples/bpf/xdp_rxq_info_user.c
> +++ b/samples/bpf/xdp_rxq_info_user.c
> @@ -489,9 +489,9 @@ int main(int argc, char **argv)
>         if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
>                 return EXIT_FAIL;
>
> -       map = bpf_map__next(NULL, obj);
> -       stats_global_map = bpf_map__next(map, obj);
> -       rx_queue_index_map = bpf_map__next(stats_global_map, obj);
> +       map =  bpf_object__find_map_by_name(obj, "config_map");
> +       stats_global_map = bpf_object__find_map_by_name(obj, "stats_global_map");
> +       rx_queue_index_map = bpf_object__find_map_by_name(obj, "rx_queue_index_map");

Yeah, relying on relative order of maps as instantiated by libbpf
internally is extremely fragile. Thanks for fixing this.

Acked-by: Andrii Nakryiko <andriin@fb.com>

>         if (!map || !stats_global_map || !rx_queue_index_map) {
>                 printf("finding a map in obj file failed\n");
>                 return EXIT_FAIL;
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions
  2019-12-02 12:37 [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions Jesper Dangaard Brouer
  2019-12-02 13:02 ` Toke Høiland-Jørgensen
  2019-12-02 17:35 ` Andrii Nakryiko
@ 2019-12-05  1:54 ` Alexei Starovoitov
  2 siblings, 0 replies; 4+ messages in thread
From: Alexei Starovoitov @ 2019-12-05  1:54 UTC (permalink / raw)
  To: Jesper Dangaard Brouer
  Cc: bpf, Jakub Kicinski, Network Development, Daniel Borkmann, Daniel T. Lee

On Mon, Dec 2, 2019 at 4:37 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>
> In the days of using bpf_load.c the order in which the 'maps' sections
> were defines in BPF side (*_kern.c) file, were used by userspace side
> to identify the map via using the map order as an index. In effect the
> order-index is created based on the order the maps sections are stored
> in the ELF-object file, by the LLVM compiler.
>
> This have also carried over in libbpf via API bpf_map__next(NULL, obj)
> to extract maps in the order libbpf parsed the ELF-object file.
>
> When BTF based maps were introduced a new section type ".maps" were
> created. I found that the LLVM compiler doesn't create the ".maps"
> sections in the order they are defined in the C-file. The order in the
> ELF file is based on the order the map pointer is referenced in the code.
>
> This combination of changes lead to xdp_rxq_info mixing up the map
> file-descriptors in userspace, resulting in very broken behaviour, but
> without warning the user.
>
> This patch fix issue by instead using bpf_object__find_map_by_name()
> to find maps via their names. (Note, this is the ELF name, which can
> be longer than the name the kernel retains).
>
> Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf")
> Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

Applied. Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-02 12:37 [bpf PATCH] samples/bpf: fix broken xdp_rxq_info due to map order assumptions Jesper Dangaard Brouer
2019-12-02 13:02 ` Toke Høiland-Jørgensen
2019-12-02 17:35 ` Andrii Nakryiko
2019-12-05  1:54 ` Alexei Starovoitov

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git