netdev - Re: [PATCH net-next 4/5] selftests: drv-net: construct environment for running tests which require an endpoint

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: <20240415073109.57629e54@kernel.org>
Date: Mon, 15 Apr 2024 07:31:09 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, shuah@...nel.org, petrm@...dia.com,
 linux-kselftest@...r.kernel.org, willemb@...gle.com
Subject: Re: [PATCH net-next 4/5] selftests: drv-net: construct environment
 for running tests which require an endpoint

On Sun, 14 Apr 2024 12:45:43 -0400 Willem de Bruijn wrote:
> Overall, this is really cool stuff (obviously)!
> 
> REMOTE instead of EP?

If I have to (:
Endpoint isn't great.
But remote doesn't seem much better, and it doesn't have a nice
abbreviation :(

> Apparently I missed the earlier discussion. Would it also be possible
> to have both sides be remote. Where the test runner might run on the
> build host, but the kernel under test is run on two test machines.
> 
> To a certain extent, same for having two equivalent child network
> namespaces isolated from the runner's environment.

I was thinking about it (and even wrote one large test which uses
2 namespaces [1]). But I could not convince myself that the added
complication is worth it.

[1] https://github.com/kuba-moo/linux/blob/psp/tools/net/ynl/psp.py

Local namespace testing is one thing, entering the namespace from
python and using the right process abstraction to make sure garbage
collector doesn't collect the namespace before the test exits it
(sigh) is all doable. But we lose the ability interact with the local
system directly when the endpoint is remote. No local FW access with
read/write, we have to "cat" and "echo" like in bash. No YNL access,
unless we ship specs and CLI over.

So I concluded that we're better off leaning on kselftest for
remote/remote. make install, copy the tests over, run them remotely.
I may be biased tho, I don't have much use for remote/remote in my
development env.

> Use FC00::/7 ULA addresses?

Doesn't ULA have some magic address selection rules which IETF 
is just trying to fix now? IIUC 0100:: is the documentation prefix,
so shouldn't be too bad?