netdev - Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0

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, 16 Jan 2019 09:13:11 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Simon Horman <simon.horman@...ronome.com>,
        Bartek Kois <bartek.kois@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Problem with queuing vlan tagged packets after migration from
 3.16.0 to 4.9.0

On 2019-01-15 1:19 p.m., Cong Wang wrote:

> 
> I never say it is broken. I am saying you only fix vlan case by
> introducing "vlanid XXX" and leave IPv4 option cases unfixed.

Let me see if we can get clarity.

IP options or TCP options typically work. You teach u32 what
to use to compute the next header. Are they now broken?

Maybe you mean that if one was to look for ip options in a
vlan tagged packet they wont find it? If yes, I would account
that to the brokenness of the vlans that we have now. But
once the vlan is popped the rule looking for protocol
ip should work. Is that broken now?

Note: Typically you will look for ip options
when you match an ip packet not when you match a vlan id etc.

> As I keep saying, this is a kinda design flaw of u32 probably
> can't be workarounded.

It is still useful to be able to match vlan ids using u32.

cheers,
jamal