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] [day] [month] [year] [list]

Message-ID: <e6f2dc5e-3491-8ace-a902-975ab42002f0@iogearbox.net>
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