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: Windows password security audit tool. GUI, reports in PDF.

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

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

On 04/08/15 09:41, Daniel Borkmann wrote:
> On 04/08/2015 03:34 PM, Jiri Pirko wrote:
>> Wed, Apr 08, 2015 at 03:27:57PM CEST, daniel@...earbox.net wrote:
>>> On 04/08/2015 03:14 PM, Thomas Graf wrote:
>>>> On 04/08/15 at 08:58am, Jamal Hadi Salim wrote:
>>>>> On 04/08/15 08:31, Daniel Borkmann wrote:
>>>>>> That means the tc's cls_u32
>>>>>> sample selectors a la ip, ip6, udp, tcp, icmp don't work on ingress
>>>>>> either,so in u32 speak you would need to do that by hand, but that
>>>>>> doesn't work as you don't have the Ethernet type context available.
>>>>>> Am I missing something? :)
>>>>>
>>>>> u32 works fine. I am sure i have tests which run these on both
>>>>> in/egress.
>>>>
>>>> His point is that an u32 filter written for egress won't work at
>>>> ingress because the offsets are different. This has always been the
>>>> case and we can't break this behaviour either. I'm sure you have
>>>> these weird negative offset u32 egress filters in your repertoire
>>>> as well ;-)
>>>
>>> Okay, you can use negative offsets in cls_u32 to accomodate for
>>> that; so yeah, you'd need to implement your filter differently
>>> on ingress. That should also work on cls_bpf et al.
>>
>> That is certainly doable. But is that what we want? I don't think so. I
>> would like to have the same for in/eg.
>
> I mean it's certainly a non-obvious hack, where user space has to
> fix up something that the kernel should have gotten right in the
> first place. :/

Try something like:
on ingress
filter add dev eth0 parent ffff: protocol ip prio 6 u32 match ip src \
10.0.0.21/32 flowid 1:16 action ok
and egress
filter add dev eth0 parent 1: protocol ip prio 6 u32 match ip src \
10.0.0.21/32 flowid 1:16 action ok

and see if you need negative offsets for anything.

If you really must adjust in the kernel then use the indicators which
tell you where you are at.

Negative offsets are used if you must go beyond the network header. This
has been the expectation so far (whether it is actions or classifiers),
example, here is something that mucks around with ethernet
headers:

tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
match ip src 192.168.1.10/32 flowid 1:2 \
action pedit munge offset -14 u16 set 0x0000 \
munge offset -12 u32 set 0x00010100 \
munge offset -8 u32 set 0x0aaf0100 \
munge offset -4 u32 set 0x0008ec06 pipe \
action mirred egress redirect dev eth1

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