netdev - Re: [PATCH next v2 0/7] Introduce l3

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: <CAF2d9jhtvvEdmwP8OrOcUEn+P-Di0TRnjR7-RpcJrKJ3+HAN-Q@mail.gmail.com>
Date:	Sun, 13 Mar 2016 19:29:58 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	mahesh@...dewar.net, Eric Dumazet <edumazet@...gle.com>,
	linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing

On Sun, Mar 13, 2016 at 6:50 PM, David Miller <davem@...emloft.net> wrote:
> From: Mahesh Bandewar <mahesh@...dewar.net>
> Date: Wed,  9 Mar 2016 13:49:49 -0800
>
>> This does happen as expected for egress traffic however on ingress
>> traffic, the IPvlan packet-handler changes the skb->dev and this
>> forces packet to be processed with the IPvlan slave and it's
>> associated ns. This causes above mentioned problem and few other
>> which are not yet reported / attempted. e.g.  IPsec with L3 mode or
>> even ingress routing.
>
> And now your changes make it so that we can't run netfilter rules on
> the slave's device within the slave's ns.
>
> If someone is doing that now you're breaking things for them.
>
Yes, I agree. If someone is using netfilter hooks in slave-ns, then this would
break for them. If we do this as a separate mode (e.g. L3s) keeping the
current mode as it is. Would that be an acceptable solution?

> It doesn't matter whether doing so or not makes sense.
>
> You're going to have to find a way to do both, and also I'm concerned
> about how you're leaking the source namespace's "stuff" into the
> destination's.  That's very worrisome to me.
>
If we add a new mode (e.g. L3s) and preserve current mode as is it, then
that should address your first concern.

Now about leaking ns "stuff". I do not want to leak stuff across ns. In the
current L3 mode there is an issue that Nicolas has pointed out and I'll fix
that soon. In the new mode (L3s); right from the beginning the L2 and L3
processing always (and consistently) will happen with master device
(proposed skb->dev->l3_dev).

> There is no way I'm applying this as-is, sorry.