netdev - Re: [RFC PATCH net-next 0/3] selftests: Add AF

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: Wed, 12 Jun 2024 09:57:04 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Magnus Karlsson <magnus.karlsson@...il.com>, 
 YiFei Zhu <zhuyifei@...gle.com>
Cc: netdev@...r.kernel.org, 
 bpf@...r.kernel.org, 
 Björn Töpel <bjorn@...nel.org>, 
 Magnus Karlsson <magnus.karlsson@...el.com>, 
 Maciej Fijalkowski <maciej.fijalkowski@...el.com>, 
 Jonathan Lemon <jonathan.lemon@...il.com>, 
 Alexei Starovoitov <ast@...nel.org>, 
 Daniel Borkmann <daniel@...earbox.net>, 
 "David S . Miller" <davem@...emloft.net>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Jesper Dangaard Brouer <hawk@...nel.org>, 
 John Fastabend <john.fastabend@...il.com>, 
 Andrii Nakryiko <andrii@...nel.org>, 
 Stanislav Fomichev <sdf@...gle.com>, 
 Willem de Bruijn <willemb@...gle.com>
Subject: Re: [RFC PATCH net-next 0/3] selftests: Add AF_XDP functionality test

Magnus Karlsson wrote:
> On Tue, 11 Jun 2024 at 22:43, YiFei Zhu <zhuyifei@...gle.com> wrote:
> >
> > We have observed that hardware NIC drivers may have faulty AF_XDP
> > implementations, and there seem to be a lack of a test of various modes
> > in which AF_XDP could run. This series adds a test to verify that NIC
> > drivers implements many AF_XDP features by performing a send / receive
> > of a single UDP packet.
> >
> > I put the C code of the test under selftests/bpf because I'm not really
> > sure how I'd build the BPF-related code without the selftests/bpf
> > build infrastructure.
> 
> Happy to see that you are contributing a number of new tests. Would it
> be possible for you to integrate this into the xskxceiver framework?

Makes sense, we'll need to take a look.

This is an internal test that we have been using for a long time in
our test framework.

My mistake for not keeping up at all with the changes to xskxceiver.c
in the meantime.

We want to test each case independently. Including a few non obvious
cases that we discovered from real use, notably

- Using XSK only for Tx, without installing an Rx program
- Using XSK with an empty fill queue, filling it after bind

> You can find that in selftests/bpf too. By default, it will run its
> tests using veth, but if you provide an interface name after the -i
> option, it will run the tests over a real interface. I put the NIC in
> loopback mode to use this feature, but feel free to add a new mode if
> necessary.

We do really want two machine tests, not loopback mode. Also to
integrate into the drv-net infrastructure.

Another non-obvious feature is to test one side AF_XDP and use
PF_PACKET on the other side, to be able to isolate and exercise only
the Tx or Rx path in a test.

> A lot of the setup and data plane code that you add already
> exists in xskxceiver, so I would prefer if you could reuse it. Your
> tests are new though and they would be valuable to have.
> 
> You could make the default packet that is sent in xskxceiver be the
> UDP packet that you want and then add all the other logic that you
> have to a number of new tests that you introduce.