netdev - Re: [RFCv2 16/16] nfp: bpf: add offload of TC direct action mode

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: <20160830125252.011f08d3@laptop>
Date:   Tue, 30 Aug 2016 12:52:52 +0200
From:   Jakub Kicinski <kubakici@...pl>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        netdev@...r.kernel.org, ast@...nel.org,
        dinan.gunawardena@...ronome.com, jiri@...nulli.us,
        john.fastabend@...il.com
Subject: Re: [RFCv2 16/16] nfp: bpf: add offload of TC direct action mode

On Mon, 29 Aug 2016 23:09:35 +0200, Daniel Borkmann wrote:
> > +	 *   0,1   ok        NOT SUPPORTED[1]
> > +	 *   2   drop  0x22 -> drop,  count as stat1
> > +	 *   4,5 nuke  0x02 -> drop
> > +	 *   7  redir  0x44 -> redir, count as stat2
> > +	 *   * unspec  0x11 -> pass,  count as stat0
> > +	 *
> > +	 * [1] We can't support OK and RECLASSIFY because we can't tell TC
> > +	 *     the exact decision made.  We are forced to support UNSPEC
> > +	 *     to handle aborts so that's the only one we handle for passing
> > +	 *     packets up the stack.  
> 
> In da mode, RECLASSIFY is not supported, so this one could be scratched.
> For the OK and UNSPEC part, couldn't both be treated the same (as in: OK /
> pass to stack roughly equivalent as in sch_handle_ingress())? Or is the
> issue that you cannot populate skb->tc_index when passing to stack (maybe
> just fine to leave it at 0 for now)?

The comment is a bit confus(ed|ing).  The problem is:

tc filter add <filter1> skip_sw
tc filter add <filter2> skip_hw

If packet appears in the stack - was it because of OK or UNSPEC (or
RECLASSIFY) in filter1?  Do we need to run filter2 or not?  Passing
tc_index can be implemented the same way I do mark today.

> Just curious, does TC_ACT_REDIRECT work in this scenario?

I do the redirects in the card, all the problems stem from the
difficulty of passing full ret code in the skb from the driver
to tc_classify()/cls_bpf_classify().