netdev - Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter ingress hooks

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: <55417F80.4000506@iogearbox.net>
Date:	Thu, 30 Apr 2015 03:04:00 +0200
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Patrick McHardy <kaber@...sh.net>,
	Pablo Neira Ayuso <pablo@...filter.org>
CC:	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org, jhs@...atatu.com
Subject: Re: [PATCH 6/6] net: move qdisc ingress filtering on top of netfilter
 ingress hooks

On 04/30/2015 02:37 AM, Patrick McHardy wrote:
> On 30.04, Pablo Neira Ayuso wrote:
>> On the bugfix front, the illegal mangling of shared skb from actions
>> like stateless nat and bpf look also important to be addressed to me.
>> David already suggested to propagate some state object that keeps a
>> pointer to the skb that is passed to the action. Thus, the action can
>> clone it and get the skb back to the ingress path. I started a
>> patchset to do so here, it's a bit large since it requires quite a lot
>> of function signature adjustment.
>
> Jumping in on this point - the fact that roughly 2/3 of TC actions will
> simply BUG under not unlikely circumstances when used in ingress (I went
> through them one by one with Pablo a week ago) is also telling. Nobody
> seems to be using that. All packet mangling actions will BUG while any
> tap is active. Its nothing easily fixed, but apparently nobody has cared
> in ten years. ipt is trivial to crash differently, connmark is as well.
>
> So I'm wondering what are we actually arguing about here. Whether we are
> affecting the performance how fast TC will crash? We *do* actually care
> about these thing, in TC apparently nobody has for the past ten years.

Totally agree with you that the situation is quite a mess. From tc ingress/
egress side, at least my use case is to have an as minimal as possible entry
point for cls_bpf/act_bpf, which is what we were working on recently. That
is rather ``fresh'' compared to the remaining history of cls/act in tc.

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