netdev - Re: [PATCH net-next] net/sched: cls_flower: Add orig

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]

Message-ID: <20210830091813.GA24951@noodle>
Date:   Mon, 30 Aug 2021 12:18:13 +0300
From:   Boris Sukholitko <boris.sukholitko@...adcom.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Vadym Kochan <vadym.kochan@...ision.eu>,
        Ilya Lifshits <ilya.lifshits@...adcom.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add orig_ethtype

Hi Vladimir,

On Mon, Aug 30, 2021 at 12:00:03PM +0300, Vladimir Oltean wrote:
[snip]
> 
> It is very good that you've followed up this discussion with a patch:
> https://patchwork.kernel.org/project/netdevbpf/patch/20210617161435.8853-1-vadym.kochan@plvision.eu/
> 
> I don't seem to see, however, in that discussion, what was the reasoning
> that led to the introduction of a new TCA_FLOWER_KEY_ORIG_ETH_TYPE as
> opposed to using TCA_FLOWER_KEY_ETH_TYPE?

While trying to implement the plan from:

https://patchwork.kernel.org/project/netdevbpf/patch/20210617161435.8853-1-vadym.kochan@plvision.eu/#24263965

I've came upon the conclusion that it is better to make new orig_ethtype key
rather than reusing TCA_FLOWER_KEY_ETH_TYPE name. The changes I've
proposed there seem of a dubious value now. IMHO, of course :)

> 
> Can you explain in English what is the objective meaning of
> TCA_FLOWER_KEY_ORIG_ETH_TYPE, other than "what I need to solve my problem"?

The orig part in the name means that the match is done on the original
protocol field of the packet, before dissector manipulation.

> Maybe an entry in the man page section in your iproute2 patch?

Yes, sure, good catch! I'll send V2 of the iproute2 patch shortly.

> 
> How will the VLAN case be dealt with? What is the current status quo on
> vlan_ethtype, will a tc-flower key of "vlan_ethtype $((ETH_P_PPP_SES))"
> match a VLAN-tagged PPP session packet or not, will the flow dissector
> still drill deep inside the packet? I guess this is the reason why you
> introduced another variant of the ETH_TYPE netlink attribute, to be
> symmetric with what could be done for VLAN? But I don't see VLAN changes?

For VLAN, I intend to add [c]vlan_orig_ethtype keys. I intend to send those
(to-be-written :)) patches separately.

Thanks,
Boris.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)