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: <20180917231513.mevvgup4y4qnrb2k@ast-mbp>
Date:   Mon, 17 Sep 2018 16:15:16 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:     Tushar Dave <tushar.n.dave@...cle.com>, ast@...nel.org,
        daniel@...earbox.net, davem@...emloft.net,
        santosh.shilimkar@...cle.com, jakub.kicinski@...ronome.com,
        quentin.monnet@...ronome.com, jiong.wang@...ronome.com,
        sandipan@...ux.vnet.ibm.com, john.fastabend@...il.com,
        kafai@...com, rdna@...com, yhs@...com, netdev@...r.kernel.org,
        rds-devel@....oracle.com
Subject: Re: [PATCH net-next 5/5] ebpf: Add sample ebpf program for
 SOCKET_SG_FILTER

On Thu, Sep 13, 2018 at 06:10:13AM -0400, Sowmini Varadhan wrote:
> On (09/12/18 19:07), Alexei Starovoitov wrote:
> > 
> > I didn't know that. The way I understand your statement that
> > this new program type, new sg logic, and all the complexity
> > are only applicable to RDMA capable hw and RDS.
> 
> I dont know if you have been following the RFC series at all 
> (and DanielB/JohnF feedback to it) but that is not what the patch 
> set is about.
> 
> To repeat a summary of the original problem statement:
> 
> RDS (hardly a "niche" driver, let's please not get carried away 
> with strong assertions based on incomplete understanding), 
> is an example of a driver that happens to pass up packets
> as both scatterlist and sk_buffs to the ULPs. 
> 
> The scatterlist comes from IB, the sk_buffs come from the ethernet
> drivers. At the moment, the only way to build firewalls for
> this is to convert scatterlist to skb and use  either netfilter
> or eBPF on the skb. What Tushar is adding is support to use eBPF
> on the scatterlist itself, so that you dont have to do this
> inefficient scatterlist->skb conversion.

if the goal is to add firewall ability to RDS then the patch set
is going in the wrong direction.
New bpf prog type and attaching to sockets isn't going to be
helpful in building firewalls.
Also there was a mention of some form of 'redirect' for some
future use? That doesn't fit the firewall goal as well.
I think it would be the best to start from scratch and discuss
the bigger goal first.
May be the right answer is to teach rds to behave like the rest of protocols.
Then all existing tooling and features will 'just work' ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ