netdev - Re: [PATCH net-next,RFC 0/9] net: sched: prepare to reuse per-block callbacks from netfilter

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]

Message-ID: <20190426115512.18263215@cakuba.netronome.com>
Date:   Fri, 26 Apr 2019 11:55:12 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Jiri Pirko <jiri@...nulli.us>, netfilter-devel@...r.kernel.org,
        davem@...emloft.net, netdev@...r.kernel.org, jiri@...lanox.com,
        john.hurley@...ronome.com, ogerlitz@...lanox.com
Subject: Re: [PATCH net-next,RFC 0/9] net: sched: prepare to reuse per-block
 callbacks from netfilter

On Fri, 26 Apr 2019 20:41:45 +0200, Pablo Neira Ayuso wrote:
> > > > >Hence, this emulates the shared blocks available in TC that Jiri made.
> > > > >
> > > > >Note that the list of tcf_block_cb objects will be called to offload
> > > > >policies in this chain.    
> > > > 
> > > > So you are going to use chain_id (if there is anything like that) as
> > > > block_index during offload, right?    
> > > 
> > > Yes. But I don't need to expose this chain_index to userspace though,
> > > I can internally allocate it, I only need to make sure it does not
> > > overlap with any of the existing tc block_indexed. I can just use a
> > > different index space which does not overlap with the tc block index
> > > space.  
> > 
> > How will the association between a block and a device work for
> > netfilter?  
> 
> My proposal is that Netfilter doesn't need to expose anything similar
> to the TC block concept. I mean, not to the user, not through the
> command line and netlink itself.

Yes, yes.

> If netfilter supports for chain definitions like this:
> 
>         table x {
>                 chain y {
>                         type filter hook ingress devices = { eth0, eth1 } priority 0;
>                 }
>         }
> 
> Then the chain 'y' implicitly becomes the block for the 'eth0' and
> 'eth1' devices.

Can there be more chains for those devices?  Or those will only run y
from netfilter perspective?

> Note that the above is not yet supported, I need to extend the netlink
> API for this, but having chains that are attached to multiple devices
> is feasible and it makes sense for plain software configurations where
> no offload is involved (as useful as the TC block for pure software to
> avoid policy duplication).