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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 May 2020 00:29:41 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Andrey Ignatov <rdna@...com> Cc: ast@...nel.org, bpf@...r.kernel.org, netdev@...r.kernel.org, sdf@...gle.com Subject: Re: [PATCH bpf-next 4/4] bpf, testing: add get{peer,sock}name selftests to test_progs On 5/19/20 12:17 AM, Andrey Ignatov wrote: > Daniel Borkmann <daniel@...earbox.net> [Mon, 2020-05-18 08:35 -0700]: >> Extend the existing connect_force_port test to assert get{peer,sock}name programs >> as well. The workflow for e.g. IPv4 is as follows: i) server binds to concrete >> port, ii) client calls getsockname() on server fd which exposes 1.2.3.4:60000 to >> client, iii) client connects to service address 1.2.3.4:60000 binds to concrete >> local address (127.0.0.1:22222) and remaps service address to a concrete backend >> address (127.0.0.1:60123), iv) client then calls getsockname() on its own fd to >> verify local address (127.0.0.1:22222) and getpeername() on its own fd which then >> publishes service address (1.2.3.4:60000) instead of actual backend. Same workflow >> is done for IPv6 just with different address/port tuples. >> >> # ./test_progs -t connect_force_port >> #14 connect_force_port:OK >> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED >> >> Signed-off-by: Daniel Borkmann <daniel@...earbox.net> >> Cc: Andrey Ignatov <rdna@...com> >> --- > >> --- a/tools/testing/selftests/bpf/network_helpers.c >> +++ b/tools/testing/selftests/bpf/network_helpers.c >> @@ -5,6 +5,8 @@ >> #include <string.h> >> #include <unistd.h> >> >> +#include <arpa/inet.h> >> + >> #include <sys/epoll.h> >> >> #include <linux/err.h> >> @@ -35,7 +37,7 @@ struct ipv6_packet pkt_v6 = { >> .tcp.doff = 5, >> }; >> >> -int start_server(int family, int type) >> +int start_server_with_port(int family, int type, int port) > > Nit: IMO it's worth to start using __u16 for ports in new places, > especially since this network helper can be adopted by many tests in the > future. I know 4-byte int-s are used for ports even in UAPI, but IMO it > just adds confusion and complicates implementation in both kernel and > user BPF programs. Ok, makes sense, I'll change the signature to __u16 port in a v2. Thanks, Daniel
Powered by blists - more mailing lists