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:	Tue, 14 Jul 2015 07:57:34 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <daniel@...earbox.net>,
	Alexei Starovoitov <ast@...mgrid.com>
CC:	David Miller <davem@...emloft.net>, jiri@...nulli.us,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tc: fix tc actions in case of shared skb

On 07/14/15 06:29, Daniel Borkmann wrote:
> On 07/14/2015 12:26 AM, Alexei Starovoitov wrote:
>> On 7/13/15 1:55 PM, Daniel Borkmann wrote:
>>> On 07/13/2015 10:17 PM, Alexei Starovoitov wrote:
>>> ...
>>>> We cannot check tc actions from pktgen, since they can be added
>>>> dynamically.
>>>> So I see three options:
>>>> 1 get rid of burst hack for both RX and TX in pktgen (kills
>>>> performance)
>>>> 2 add unlikely(skb_shread) check to few tc actions
>>>> 3 do nothing
>> ...
>>> pktgen case. :/ With regards to option 2, you could hide that behind
>>> a static inline helper wrapped in IS_ENABLED(CONFIG_NET_PKTGEN), but
>>> that is a veeeery ugly workaround/hack as well (and distros might
>>> even ship it nevertheless).
>>
>> naming such helper is a headache as well.
>> static inline bool is_pktgen_shared_skb(struct sk_buff *skb)
>> {
>> #if IS_ENABLED(CONFIG_NET_PKTGEN)
>>      /* pktgen uses skb->users += burst trick to reuse skb */
>>      return skb_shared(skb);
>> #else
>>      return false;
>> #endif
>> }
>> and in actions:
>> if (unlikely(is_pktgen_shared_skb(skb))) goto drop;
>>
>> thoughts?
>
> As I mentioned above, so Fedora, for example, ships pktgen by default.
> That means, we'd run into the above test for shared skb in every case,
> meaning it won't help much and it's also a pretty nasty hack. ;)
>
> One other thing that comes to mind, not sure if it's worth it though,
> would be to split the skb->tc_verd's TC_NCLS itself into TC_NCLS/TC_NACT,
> so that you can go into the classifier, but skip the action part.
>
> Since in tcf_action_exec(), we already test for that, you might be able
> to add this with no extra cost. pktgen would then need to tag its skb
> with TC_NACT, so that you'll always return with TC_ACT_OK. And if you
> really would want to test tc actions, then w/o pktgen bursting ...
>

Would just a simple skb->mark not work? Drop if skb->mark = x
using skbedit. Or a brand new pktgen_burst_mode action that drops?

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ