netdev - Re: [PATCH v2 net-next 3/4] selftests: fcnal: Test SO

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]

Date: Thu, 11 May 2023 17:55:59 +0200
From: Guillaume Nault <gnault@...hat.com>
To: David Ahern <dsahern@...nel.org>
Cc: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next 3/4] selftests: fcnal: Test SO_DONTROUTE on
 UDP sockets.

On Thu, May 11, 2023 at 09:03:44AM -0600, David Ahern wrote:
> On 5/11/23 8:39 AM, Guillaume Nault wrote:
> > Use nettest --client-dontroute to test the kernel behaviour with UDP
> > sockets having the SO_DONTROUTE option. Sending packets to a neighbour
> > (on link) host, should work. When the host is behind a router, sending
> > should fail.
> > 
> > Signed-off-by: Guillaume Nault <gnault@...hat.com>
> > ---
> >  v2: Use 'nettest -B' instead of invoking two nettest instances for
> >      client and server.
> > 
> >  tools/testing/selftests/net/fcnal-test.sh | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh
> > index 3a1f3051321f..08b4b96cbd63 100755
> > --- a/tools/testing/selftests/net/fcnal-test.sh
> > +++ b/tools/testing/selftests/net/fcnal-test.sh
> > @@ -1641,6 +1641,23 @@ ipv4_udp_novrf()
> >  	log_start
> >  	run_cmd nettest -D -d ${NSA_DEV} -r ${a}
> >  	log_test_addr ${a} $? 2 "No server, device client, local conn"
> > +
> > +	#
> > +	# Link local connection tests (SO_DONTROUTE).
> > +	# Connections should succeed only when the remote IP address is
> > +	# on link (doesn't need to be routed through a gateway).
> > +	#
> > +
> > +	a=${NSB_IP}
> > +	log_start
> > +	do_run_cmd nettest -B -D -N "${NSA}" -O "${NSB}" -r ${a} --client-dontroute
> > +	log_test_addr ${a} $? 0 "SO_DONTROUTE client"
> > +
> > +	a=${NSB_LO_IP}
> > +	log_start
> > +	show_hint "Should fail 'Network is unreachable' since server is not on link"
> > +	do_run_cmd nettest -B -D -N "${NSA}" -O "${NSB}" -r ${a} --client-dontroute
> > +	log_test_addr ${a} $? 1 "SO_DONTROUTE client"
> >  }
> >  
> >  ipv4_udp_vrf()
> 
> Reviewed-by: David Ahern <dsahern@...nel.org>
> 
> Have you looked at test cases with VRF - both UDP and TCP?

I haven't looked at the VRF cases. I don't really see what kernel path
I could cover that isn't already covered by the non-vrf cases:

  * From ns-B point of view, VRF_IP is just a routed IP, like NSA_LO_IP.
    So testing SO_DONTROUTE on a socket belonging to ns-B wouldn't
    cover any new kernel code path.

  * From ns-A point of view, the routing table content is the same. It
    just has to use table $VRF_TABLE instead of main. So the test would
    just ensure that we jump to the right routing table, something that
    SO_DONTROUTE doesn't influences. But the route lookup itself is
    actually the same as for the non-vrf test (just using a different
    table). Therefore I feel that adding vrf tests for SO_DONTROUTE
    wouldn't bring much value.

But I may very well be missing some interesting points. If you have any
VRF test case in mind, I can add them.