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:   Fri, 11 Nov 2016 08:28:50 +0000
From:   Yotam Gigi <yotamg@...lanox.com>
To:     John Fastabend <john.fastabend@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        Ido Schimmel <idosch@...lanox.com>,
        Elad Raz <eladr@...lanox.com>,
        Nogah Frankel <nogahf@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "geert+renesas@...der.be" <geert+renesas@...der.be>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>
Subject: RE: [patch net-next 5/8] Introduce sample tc action

>-----Original Message-----
>From: Yotam Gigi
>Sent: Thursday, November 10, 2016 9:59 PM
>To: 'John Fastabend' <john.fastabend@...il.com>; Jiri Pirko <jiri@...nulli.us>;
>netdev@...r.kernel.org
>Cc: davem@...emloft.net; Ido Schimmel <idosch@...lanox.com>; Elad Raz
><eladr@...lanox.com>; Nogah Frankel <nogahf@...lanox.com>; Or Gerlitz
><ogerlitz@...lanox.com>; jhs@...atatu.com; geert+renesas@...der.be;
>stephen@...workplumber.org; xiyou.wangcong@...il.com; linux@...ck-us.net;
>roopa@...ulusnetworks.com
>Subject: RE: [patch net-next 5/8] Introduce sample tc action
>
>
>
>>-----Original Message-----
>>From: John Fastabend [mailto:john.fastabend@...il.com]
>>Sent: Thursday, November 10, 2016 9:38 PM
>>To: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org
>>Cc: davem@...emloft.net; Yotam Gigi <yotamg@...lanox.com>; Ido Schimmel
>><idosch@...lanox.com>; Elad Raz <eladr@...lanox.com>; Nogah Frankel
>><nogahf@...lanox.com>; Or Gerlitz <ogerlitz@...lanox.com>;
>>jhs@...atatu.com; geert+renesas@...der.be; stephen@...workplumber.org;
>>xiyou.wangcong@...il.com; linux@...ck-us.net; roopa@...ulusnetworks.com
>>Subject: Re: [patch net-next 5/8] Introduce sample tc action
>>
>>On 16-11-10 11:35 AM, John Fastabend wrote:
>>> On 16-11-10 03:23 AM, Jiri Pirko wrote:
>>>> From: Yotam Gigi <yotamg@...lanox.com>
>>>>
>>>> This action allow the user to sample traffic matched by tc classifier.
>>>> The sampling consists of choosing packets randomly, truncating them,
>>>> adding some informative metadata regarding the interface and the original
>>>> packet size and mark them with specific mark, to allow further tc rules to
>>>> match and process. The marked sample packets are then injected into the
>>>> device ingress qdisc using netif_receive_skb.
>>>>
>>>> The packets metadata is packed using the ife encapsulation protocol, and
>>>> the outer packet's ethernet dest, source and eth_type, along with the
>>>> rate, mark and the optional truncation size can be configured from
>>>> userspace.
>>>>
>>>> Example:
>>>> To sample ingress traffic from interface eth1, and redirect the sampled
>>>> the sampled packets to interface dummy0, one may use the commands:
>>>>
>>>> tc qdisc add dev eth1 handle ffff: ingress
>>>>
>>>> tc filter add dev eth1 parent ffff: \
>>>> 	   matchall action sample rate 12 mark 17
>>>>
>>>> tc filter add parent ffff: dev eth1 protocol all \
>>>> 	   u32 match mark 17 0xff \
>>>> 	   action mirred egress redirect dev dummy0
>>>>
>>>> Where the first command adds an ingress qdisc and the second starts
>>>> sampling every 12'th packet on dev eth1 and marks the sampled packets with
>>>> 17. The third command catches the sampled packets, which are marked with
>>>> 17, and redirects them to dev dummy0.
>>>
>>> The sampling algorithm was not randomized based on the above commit
>>> log? It really needs to be for all the reasons Roopa mentioned earlier.
>>> Did I miss some email on why it didn't get implemented?
>>>
>>> Also there was an indication the already is actually implemented
>>> correctly so don't we need the hw/sw to behave the same. The whole
>>> argument about sw/hw parity, etc.
>>
>>sorry bit of a typo there corrected 2nd paragraph here...
>>
>>Also there was an indication the hardware is already implemented \
>>correctly so don't we need the hw/sw to behave the same. The argument
>>about sw/hw parity, etc.
>
>Our hardware currently does not support sampling with random behavior, so
>we did implement it in software too.
>
>But, the API is extensible and it is possible to add a random keyword to
>the tc action to allow random sampling. In that case, the keyword will be
>implemented in sw only and our driver will fail offloading it.
>

John, as a result of your question I realized that our hardware does do 
randomized sampling that I was not aware of. I will use the extensibility of
the API and implement a random keyword, that will be offloaded in our 
hardware. Those changes will be sent on v2.

Eventually, your question was very relevant :) Thanks!

>>
>>>
>>>>
>>>> Signed-off-by: Yotam Gigi <yotamg@...lanox.com>
>>>> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>>>> ---
>>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ