Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 11:59 AM, Jesper Dangaard Brouer
[off-list ref] wrote:

On Tue, 20 Sep 2016 10:39:20 -0700
Eric Dumazet [off-list ref] wrote:

quoted

On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote:

quoted

because 'div by zero' is an abnormal situation that shouldn't be exploited.
Meaning if xdp program is doing DoS prevention and it has a bug that
attacker can now exploit by sending a crafted packet that causes
'div by zero' and kernel will warn then attack got successful.
Therefore it has to be silent drop.

A silent drop means a genuine error in a BPF program might be never
caught, since a tracepoint might never be enabled.

I do see your point. But we can document our way out of it.

quoted

quoted

tracpoint in such case is great, since the user can do debugging with it
and even monitoring 24/7 and if suddenly the control plan sees a lot
of such trace_xdp_abotred events, it can disable that tracepoint to avoid
spam and adjust the program or act on attack some other way.
Hardcoded warnings and counters are not generic enough for all
the use cases people want to throw at XDP.
The tracepoints idea is awesome, in a sense that it's optional.

Note that tracepoints are optional in a kernel.

Well, that is a good thing, as it can be compiled out (as that provides
an option for zero cost).

quoted

Many existing supervision infrastructures collect device snmp
counters, and run as unprivileged programs.

A supervision infrastructures is a valid use-case. It again indicate
that such XDP stats need to structured, not just a random driver
specific ethtool counter, to make it easy for such collection daemons.

I am currently adding a structure to define an XDP hook (plan to post
patches shortly). Counters can be added to that in a uniform fashion
that doesn't need code in every driver.

Tom

quoted

tracepoints might not fit the need here, compared to a mere
tx_ring->tx_drops++

I do see your point.  I really liked the tracepoint idea, but now I'm
uncertain again...


I do have a use-case where I want to use the NIC HW-RX-ingress-overflow
and TX-overflow drop indicators, but I don't want to tie it into this
discussion.  The abort and error indicators a not relevant for that
use-case.

--
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer