netdev - Re: BPF for hash calculation

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>] [day] [month] [year] [list]

Date:   Wed, 20 May 2020 02:35:56 +0000
From:   Ariel Levkovich <lariel@...lanox.com>
To:     "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Jiri Pirko <jiri@...lanox.com>
CC:     Roni Bar Yanai <roniba@...lanox.com>,
        Majd Dibbiny <majd@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: BPF for hash calculation

On May 19, 2020, at 22:13, Ariel Levkovich <lariel@...lanox.com> wrote:
> 
> Hi Daniel, Aleksei
> 
> I’m working on a feature to add support for datapath hash actions and matching via TC API.
> 
> One of the options we want to offer users there is to provide their own hash calculation function, in the form of a BPF program.
> The program should accept struct __sk_buff and return a hash value.
> 
> After a little research and testing I noticed that some key parameters in struct __sk_buff are sertricted to BPF_PROG_TYPE_SK_SKB program types while I was planning to re-use the existing  BPF_PROG_TYPE_SCHED_ACT program type for the act_hash purpose.
> The key parameters I’m referring to are fields like remote_ip4, local_ip4, src/dst_port (flow key fields) that are most likely going to be relevant for hash calculation on a packet.
> 
> So my question to you is basically what is the best option here? The way I see it the options are:
> 1. Remove restrictions on these fields for SCHED_ACT program type in kernel/bpf/verifier.c
> 2. Add new program type SCHED_ACT_HASH with permission to access these fields.
> 3. More of a question - is there another way to access the flow keys via struct __sk_buff?
> 
> Appreciate your advice and thanks in advance.
> 
> Best Regards,
> 
> Ariel Levkovich
> Staff engineer, Mellanox SW

Forgot to CC relevant mailing list.
After further digging it seems there’s a pointer to a flow keys struct that is not restricted to SK_SKB prog types and should be our best option. The question remains whether we can reuse SCHED_ACT type or a new type for hash calculation should be added?