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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ