netdev - Re: [net-next PATCH v3 3/8] net: sched: add cls

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

Message-ID: <56C71011.7060105@mojatatu.com>
Date:	Fri, 19 Feb 2016 07:52:33 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	John Fastabend <john.fastabend@...il.com>, jiri@...nulli.us,
	amir@...ai.me, davem@...emloft.net
Cc:	netdev@...r.kernel.org, jeffrey.t.kirsher@...el.com
Subject: Re: [net-next PATCH v3 3/8] net: sched: add cls_u32 offload hooks for
 netdevs

On 16-02-18 10:24 AM, John Fastabend wrote:
> On 16-02-18 04:14 AM, Jamal Hadi Salim wrote:
>> On 16-02-17 06:07 PM, John Fastabend wrote:
>>> [...]
>>>
>>

>> IMO, it would be better at this early stage to enforce the correct
>> behavior for future generations.
>> To follow the netlink semantics which a lot of people are already
>> trained to think in.
>>
>> Current netlink behavior is supposed to be:
>>
>> 1) NEW ==> "Create".
>> Ambigous - could mean a)"create if it doesnt exist" or b) "fail if it
>> exists otherwise create"
>> Unfortunately different parts of the kernel often assume some
>> default from either #a or #b.
>>
>
> But this is already handled by the core cls_api.c code. We never
> get to u32_change if the flags are not correct.
>
> Look at the block right above the op call into the classifiers
> change() code in cls_api.c. Starting at line 287.
>
>

Indeed that would cover s/ware filters but not h/ware. That will
depend on what hardware can do. Really,
all you need is to propagate those flags. Your
driver ndo can ignore them. I know i will need them.

Alternatively: If we say all filters are going to be stored in
s/ware as well i.e the tri-state we talked about then the cls_api
checks will work as well. But when you are talking millions
of filters (such as i deal with) - that may become impractical
(and then you are going to have all kind of clever things to find
whether an EXCLUSIVE will work or not etc).

cheers,
jamal