netdev - Re: [PATCH next 3/3] net: Use l3_dev instead of skb->dev for L3 processing

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, 2 Mar 2016 20:45:36 -0800
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Mahesh Bandewar <mahesh@...dewar.net>
Cc:	David Miller <davem@...emloft.net>,
	Mahesh Bandewar <maheshb@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	netdev <netdev@...r.kernel.org>, Tim Hockin <thockin@...gle.com>,
	Alex Pollitt <alex.pollitt@...aswitch.com>,
	Matthew Dupre <matthew.dupre@...aswitch.com>
Subject: Re: [PATCH next 3/3] net: Use l3_dev instead of skb->dev for L3 processing

On Mon, Feb 29, 2016 at 2:08 PM, Mahesh Bandewar <mahesh@...dewar.net> wrote:
> From: Mahesh Bandewar <maheshb@...gle.com>
>
> netif_receive_skb_core() dispatcher uses skb->dev device to send it
> to the packet-handlers (e.g. ip_rcv, ipv6_rcv etc). These packet
> handlers intern use the device passed to determine the net-ns to
> further process these packets.  Now with the nomination logic, the
> dispatcher will call netif_get_l3_dev() helper to select the device
> to be used for this processing. Since l3_dev is initialized to self,
> normal packet processing should not change.
>

So, if I understand your patches correctly, _logically_ the skb is still
passed into the slave's netns via dev_forward_skb() but now goes over
the iptable rules from the default netns by only changing the netns
parameter to these hooks?

That is ugly... Logically, you should still need to continue to pass
the skb upper to the stack in default netns until ip_local_deliver_finish().

So, how about adding an iptable hook in ipvlan so that skb will
continue traverse in the original stack and then moved into slave's
netns? This might be harder since logically we need an L3 entrance
to the stack.

Thoughts?