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  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:   Tue, 3 Jan 2017 06:44:16 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     John Fastabend <john.fastabend@...il.com>,
        Paul Blakey <paulb@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Cc:     Jiri Pirko <jiri@...lanox.com>,
        Hadar Hen Zion <hadarh@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Roi Dayan <roid@...lanox.com>, Roman Mashak <mrv@...atatu.com>,
        Simon Horman <simon.horman@...ronome.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add user specified data

On 17-01-02 11:33 PM, John Fastabend wrote:
> On 17-01-02 05:22 PM, Jamal Hadi Salim wrote:

[..]
>> Like all cookie semantics it is for storing state. The receiver (kernel)
>> is not just store it and not intepret it. The user when reading it back
>> simplifies what they have to do for their processing.
>>
>>>
>>> The tuple <ifindex:qdisc:prio:handle> really should be unique why
>>> not use this for system wide mappings?
>>>
>>
>> I think on a single machine should be enough, however:
>> typically the user wants to define the value in a manner that
>> in a distributed system it is unique. It would be trickier to
>> do so with well defined values such as above.
>>
>
> Just extend the tuple <hostname:ifindex:qdisc:prio:handle> that
> should be unique in the domain of hostname's, or use some other domain
> wide machine identifier.
>

May work for the case of filter identification. The nice thing for
allowing cookies is you can let the user define it define their
own scheme.

> Although actions can be shared so the cookie can be shared across
> filters. Maybe its useful but it doesn't uniquely identify a filter
> in the shared case but the user would have to specify that case
> so maybe its not important.
>

Note: the action cookies and filter cookies are unrelated/orthogonal.
Their basic concept of stashing something in the cookie to help improve
what user space does (in our case millions of actions of which some are
used for accounting) is similar.
I have no objections to the flow cookies; my main concern was it should
be applicable to all classifiers not just flower. And the arbitrary size
of the cookie that you pointed out is questionable.

cheers,
jamal

Powered by blists - more mailing lists