netdev - Re: [PATCH net-next 5/5] ebpf: Add sample ebpf program for SOCKET_SG

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]

Date:   Wed, 12 Sep 2018 19:07:59 -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 Wed, Sep 12, 2018 at 08:59:54PM -0400, Sowmini Varadhan wrote:
> > On 09/11/2018 09:00 PM, Alexei Starovoitov wrote:
> > >please no samples.
> > >Add this as proper test to tools/testing/selftests/bpf
> > >that reports PASS/FAIL and can be run automatically.
> > >samples/bpf is effectively dead code.
> 
> Just a second.
> 
> You do realize that RDS is doing real networking, so it needs
> RDMA capable hardware to test the rds_rdma paths? Also, when we
> "talk to ourselves" we default to the rds_loop transport, so
> we would even bypass the rds-tcp module.
> 
> I dont think this can be tested with some academic "test it 
> over lo0" exercise.. I suppose you can add example code in
> sefltests for this, but asking for a "proper test" may be
> a litte unrealistic here- a proper test needs proper hardware
> in this case.

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.
In such case, I think, such BPF extensions do not belong
in the upstream kernel. I don't want BPF to support niche technologies,
since the maintenance overhead makes it prohibitive long term.
If the kernel had a way to deprecate the api it would have been
different story. Every new feature and bpf extension lands once
and then being maintained forever. Hence we have to be very
selective weighting the benefits vs long term maintenance.
I'm happy to review the code further and suggest improvements,
but it's not going to be applied.