netdev - Re: [PATCH net-next 3/3] net/sched: Introduce act

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: <20160822205137.30cda14f@griffin>
Date:   Mon, 22 Aug 2016 20:51:37 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Amir Vadai <amir@...ai.me>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Hadar Har-Zion <hadarh@...lanox.com>
Subject: Re: [PATCH net-next 3/3] net/sched: Introduce act_iptunnel

On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:
> Jiri B > I understand the motivation for the decap action. However, what would
> Jiri B > happen if someone does not include it?
> 
> The MD set by the (say) vxlan device will not be "consumed" (cleared)
> and would be keep travelling with the SKB

Of course it would. That's not what I meant by the question :-)

There are three options:

1. It does not matter, as the metadata_dst will be freed anyway before
   it reaches tx path. This means we do not need the 'decap' action.

2. We may run into problems like tx path seeing the metadata_dst that
   it should not see. This means either this situation or such
   configuration must be prevented somehow.

3. The metadata_dst can reach the tx path but it doesn't matter, as it
   would just mean the packet is encapsulated into the same outer
   headers it was received with or the metadata_dst would be ignored
   (for non-tunnel interfaces).

Which one is it? Quickly looking into the code, tcf_mirred calls
dev_queue_xmit which indicates it's either 2 or 3. If it's 3., it
should be explained in the patch description (especially the non-tunnel
interface case) and documented.

 Jiri