netdev - Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw

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:   Thu, 28 Jun 2018 16:29:09 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
        xiyou.wangcong@...il.com, jakub.kicinski@...ronome.com,
        simon.horman@...ronome.com, john.hurley@...ronome.com,
        mlxsw@...lanox.com, sridhar.samudrala@...el.com
Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates
 support with offloading to mlxsw

Thu, Jun 28, 2018 at 04:18:47PM CEST, dsahern@...il.com wrote:
>On 6/28/18 7:08 AM, Jiri Pirko wrote:
>> Create dummy device with clsact first:
>> # ip link add type dummy
>> # tc qdisc add dev dummy0 clsact
>> 
>> There is no template assigned by default:
>> # tc chaintemplate show dev dummy0 ingress
>> 
>> Add a template of type flower allowing to insert rules matching on last
>> 2 bytes of destination mac address:
>> # tc chaintemplate add dev dummy0 ingress proto ip flower dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF
>> 
>> The template is now showed in the list:
>> # tc chaintemplate show dev dummy0 ingress
>> chaintemplate flower chain 0 
>>   dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff
>>   eth_type ipv4
>> 
>> Add another template, this time for chain number 22:
>> # tc chaintemplate add dev dummy0 ingress proto ip chain 22 flower dst_ip 0.0.0.0/16
>> # tc chaintemplate show dev dummy0 ingress
>> chaintemplate flower chain 0 
>>   dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff
>>   eth_type ipv4
>> chaintemplate flower chain 22 
>>   eth_type ipv4
>>   dst_ip 0.0.0.0/16
>> 
>> Add a filter that fits the template:
>> # tc filter add dev dummy0 ingress proto ip flower dst_mac aa:bb:cc:dd:ee:ff/00:00:00:00:00:0F action drop
>> 
>> Addition of filters that does not fit the template would fail:
>> # tc filter add dev dummy0 ingress proto ip flower dst_mac aa:11:22:33:44:55/00:00:00:FF:00:00 action drop
>> Error: Mask does not fit the template.
>> We have an error talking to the kernel, -1
>> # tc filter add dev dummy0 ingress proto ip flower dst_ip 10.0.0.1 action drop
>> Error: Mask does not fit the template.
>> We have an error talking to the kernel, -1
>> 
>> Additions of filters to chain 22:
>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1/8 action drop
>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1 action drop
>> Error: Mask does not fit the template.
>> We have an error talking to the kernel, -1
>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1/24 action drop
>> Error: Mask does not fit the template.
>> We have an error talking to the kernel, -1
>> 
>> Removal of a template from non-empty chain would fail:
>> # tc chaintemplate del dev dummy0 ingress
>> Error: The chain is not empty, unable to delete template.
>> We have an error talking to the kernel, -1
>
>Why this restriction? It's a template, so why can't it be removed
>regardless of whether there are filters?

That means you could start to insert filters that does not match the
original template. I wanted to avoid it. The chain is utilized in hw for
the original template, the filter insertion would have to be sanitized
in driver. With this restriction, drivers can depend on filters always
be fitting.


>
>> 
>> Once the chain is flushed, the template could be removed:
>> # tc filter del dev dummy0 ingress
>> # tc chaintemplate del dev dummy0 ingress
>> 
>