netdev - Re: [PATCH v2 net-next 2/2] tc: make ingress and egress qdiscs consistent

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]

Message-ID: <55251556.4040900@mojatatu.com>
Date:	Wed, 08 Apr 2015 07:47:34 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <daniel@...earbox.net>,
	Jiri Pirko <jiri@...nulli.us>
CC:	Alexei Starovoitov <ast@...mgrid.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	tgraf@...g.ch
Subject: Re: [PATCH v2 net-next 2/2] tc: make ingress and egress qdiscs consistent

Should have read my emails backward. Refer to my other email
So why are you not able to use the indicators of where in the stack
you are in both actions and classifiers?
bpf needs to adjust.

cheers,
jamal

On 04/08/15 07:14, Daniel Borkmann wrote:
> On 04/08/2015 12:54 PM, Daniel Borkmann wrote:
>> On 04/08/2015 11:05 AM, Jiri Pirko wrote:
>
> Generically adjusting egress towards ingress would not work. I
> think it's reasonable to assume that the majority of people use
> classifier and actions only from egress side, and they rely on
> having l2 context present. Stripping that away would also be an
> artificial limitation we'd impose.
>
> You could use the ingress qdisc to redirect traffic to an ifb
> device and attach the same egress classifier and action there
> as skb_pull(skb, skb->dev->hard_header_len) is being done, but
> I'd presume that extra detour is pretty slow. To make this useful,
> we'd need a very lightweight solution.
>
>>> having more ingres queue disk. Would be just confusing.
>>
>> I'm all for it, that's what I've mentioned earlier in this thread
>> already. ;) The above would be one possibility, but of course I'm
>> open for other, better suggestions?
>>
>> I totally agree with Dave that skb_share_check() should be avoided
>> at all costs. At least on my laptop (maybe not a perfect example),
>> I've got these as packet socket users present in the background,
>> so there are packet users running all the time where we would hit
>> skb_share_check() then:
>>
>> # ss -0lnp
>> Netid  State      Recv-Q Send-Q      Local Address:Port    Peer
>> Address:Port
>> p_raw  UNCONN     0      0                *:wlp2s0b1       *
>> users:(("dhclient",1290,5))
>> p_dgr  UNCONN     0      0          [34958]:wlp2s0b1       *
>> users:(("wpa_supplicant",805,13))
>> p_dgr  UNCONN     0      0              [0]:*              *
>> users:(("wpa_supplicant",805,12))
>>
>> I do not yet see a generic way to push an offset down into various
>> classifiers and actions that otherwise don't really work with ingress,
>> it's not just limited to BPF only as Alexei already mentioned. Hm.
>>
>> Cheers,
>> 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