netdev - Re: [PATCH net-next v5 0/7] selftests: drv-net: support testing with a remote system

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 for Android: free password hash cracker in your pocket

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

Date: Tue, 23 Apr 2024 13:57:45 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 davem@...emloft.net
Cc: netdev@...r.kernel.org, 
 edumazet@...gle.com, 
 pabeni@...hat.com, 
 shuah@...nel.org, 
 petrm@...dia.com, 
 linux-kselftest@...r.kernel.org, 
 willemdebruijn.kernel@...il.com, 
 Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next v5 0/7] selftests: drv-net: support testing with
 a remote system

Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > Hi!
> > 
> > Implement support for tests which require access to a remote system /
> > endpoint which can generate traffic.
> > This series concludes the "groundwork" for upstream driver tests.
> > 
> > I wanted to support the three models which came up in discussions:
> >  - SW testing with netdevsim
> >  - "local" testing with two ports on the same system in a loopback
> >  - "remote" testing via SSH
> > so there is a tiny bit of an abstraction which wraps up how "remote"
> > commands are executed. Otherwise hopefully there's nothing surprising.
> > 
> > I'm only adding a ping test. I had a bigger one written but I was
> > worried we'll get into discussing the details of the test itself
> > and how I chose to hack up netdevsim, instead of the test infra...
> > So that test will be a follow up :)
> > 
> > v5:
> >  - fix rand port generation, and wrap it in a helper in case
> >    the random thing proves to be flaky
> >  - reuseaddr
> >  - explicitly select the address family
> > v4: https://lore.kernel.org/all/20240418233844.2762396-1-kuba@kernel.org
> >  - improve coding style of patch 5
> >  - switch from netcat to socat (patch 6)
> >  - support exit_wait for bkg() in context manager
> >  - add require_XYZ() helpers (patch 7)
> >  - increase timeouts a little (1,3 -> 5 sec)
> > v3: https://lore.kernel.org/all/20240417231146.2435572-1-kuba@kernel.org
> >  - first two patches are new
> >  - make Remote::cmd() return Popen() object (patch 3)
> >  - always operate on absolute paths (patch 3)
> >  - last two patches are new
> > v2: https://lore.kernel.org/all/20240416004556.1618804-1-kuba@kernel.org
> >  - rename endpoint -> remote
> >  - use 2001:db8:: v6 prefix
> >  - add a note about persistent SSH connections
> >  - add the kernel config
> > v1: https://lore.kernel.org/all/20240412233705.1066444-1-kuba@kernel.org
> > 
> > Jakub Kicinski (7):
> >   selftests: drv-net: define endpoint structures
> >   selftests: drv-net: factor out parsing of the env
> >   selftests: drv-net: construct environment for running tests which
> >     require an endpoint
> >   selftests: drv-net: add a trivial ping test
> >   selftests: net: support matching cases by name prefix
> >   selftests: drv-net: add a TCP ping test case (and useful helpers)
> >   selftests: drv-net: add require_XYZ() helpers for validating env
> 
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>

Too late, but 

Tested-by: Willem de Bruijn <willemb@...gle.com>

I tried this yesterday on a pair of Google cloud instances. In
anticipation of converting some of my tests, like csum to this.

Only possible non-obvious observation is that some kselftests expect
as root, and the ssh remote logic extends that to expecting ssh
root access to the remote host.

Would it make sense to explicitly add sudo for all privileged
operations, to allow for non-root ssh and scp?