On Tue, Sep 20, 2016 at 11:59 AM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > On Tue, 20 Sep 2016 10:39:20 -0700 > Eric Dumazet <eric.duma...@gmail.com> wrote: > >> On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote: >> >> > 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. > >> > 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). > > >> 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 > >> 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
