netdev - Re: [PATCH net-next,v5 3/4] net: flow_offload: mangle action at byte level

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: <20191017162237.h4e6bdoosd5b2ipj@salvia>
Date:   Thu, 17 Oct 2019 18:22:37 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, jiri@...nulli.us, saeedm@...lanox.com,
        vishal@...lsio.com, vladbu@...lanox.com, ecree@...arflare.com
Subject: Re: [PATCH net-next,v5 3/4] net: flow_offload: mangle action at byte
 level

On Thu, Oct 17, 2019 at 06:11:57PM +0200, Pablo Neira Ayuso wrote:
[...]
> >  (3) it causes loss of functionality (looks like a single u32 changing
> >      both sport and dport is rejected by the IR since it wouldn't
> >      match fields);
> 
> Not correct.
> 
> tc filter add dev eth0 protocol ip \
>         parent ffff: \
>         pref 11 \
>         flower ip_proto tcp \
>         dst_port 80 \
>         src_ip 1.1.2.3/24 \
>         action pedit ex munge tcp src 2004 \
>         action pedit ex munge tcp dst 80
> 
> This results in two independent tc pedit actions:
> 
> * One tc pedit action with one single key, with value 0xd4070000 /
>   0x0000ffff.
> * Another tc pedit action with one single key, with value 0x00005000
>   / 0xffff0000.
> 
> This works perfectly with this patchset.

You refer to single u32 word changing both sport and dport.

What's the point with including this in the subset of the uAPI to be
supported?

In software, it really makes sense to use this representation since it
is speeding up packet processing.

In hardware, supporting this uAPI really gets you nothing at all.

We have to document what subset of the uAPI is support through
hardware offloads. Pretending that we can support all uAPI is not
true, we only support for tc pedit extended mode right now.