netdev - Re: [PATCH bpf-next v6 1/7] net: bonding: Refactor bond_xmit_hash for use with xdp

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: <3b0657f0-d7ef-e568-57c2-0db41acea615@redhat.com>
Date:   Wed, 11 Aug 2021 10:05:13 -0400
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     Jussi Maki <joamaki@...il.com>
Cc:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>, j.vosburgh@...il.com,
        Andy Gospodarek <andy@...yhouse.net>, vfalico@...il.com,
        Andrii Nakryiko <andrii@...nel.org>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>
Subject: Re: [PATCH bpf-next v6 1/7] net: bonding: Refactor bond_xmit_hash for
 use with xdp_buff

On 8/11/21 4:22 AM, Jussi Maki wrote:
> Hi Jonathan,
> 
> Thanks for catching this. You're right, this will NULL deref if XDP
> bonding is used with the VLAN_SRCMAC xmit policy. I think what
> happened was that a very early version restricted the xmit policies
> that were applicable, but it got dropped when this was refactored.
> I'll look into this today and will add in support (or refuse) the
> VLAN_SRCMAC xmit policy and extend the tests to cover this.

In support of some customer requests and to stop adding more and more 
hashing policies I was looking at adding a custom policy that exposes a 
bitfield so userspace can select which header items should be included 
in the hash. I was looking at a flow dissector implementation to parse 
the packet and then generate the hash from the flow data pulled. It 
looks like the outer hashing functions as they exist now, 
bond_xmit_hash() and bond_xmit_hash_xdp(), could make the correctly 
formatted call to __skb_flow_dissect(). We would then pass around the 
resultant struct flow_keys, or bonding specific one to add MAC header 
parsing support, and it appears we could avoid making the actual hashing 
functions know if they need to hash an sk_buff vs xdp_buff. What do you 
think?

-Jon