netdev - Re: [PATCH bpf-next 4/4] bpf, testing: add get{peer,sock}name selftests to test

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200518221728.GA49655@rdna-mbp.dhcp.thefacebook.com>
Date:   Mon, 18 May 2020 15:17:28 -0700
From:   Andrey Ignatov <rdna@...com>
To:     Daniel Borkmann <daniel@...earbox.net>
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

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.


-- 
Andrey Ignatov