netdev - Re: [PATCH net-next] tc: fix tc actions in case of shared skb

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jul 2015 12:29:13 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Alexei Starovoitov <ast@...mgrid.com>
CC:	David Miller <davem@...emloft.net>, jhs@...atatu.com,
	jiri@...nulli.us, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tc: fix tc actions in case of shared skb

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

Best,
Daniel
--
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