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, 4 Feb 2015 21:33:59 +0100
From:	Arvid Brodin <arvid.brodin@...en.se>
To:	<nicolas.dichtel@...nd.com>, <netdev@...r.kernel.org>
CC:	<davem@...emloft.net>, <dmitry.tarnyagin@...kless.no>,
	<alex.aring@...il.com>, <linux-wpan@...r.kernel.org>
Subject: Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]

On 2015-02-02 16:58, Nicolas Dichtel wrote:
> Le 30/01/2015 21:00, Arvid Brodin a écrit :
>> On 2015-01-26 22:28, Nicolas Dichtel wrote:
>> *snip*
>>> - HSR subsystem uses src_net to parse IFLA_HSR_SLAVE[1|2], but the netdevice has
>>>    the flag NETIF_F_NETNS_LOCAL, so the question is: does this netdevice really
>>>    supports x-netns? If not, the newlink handler should use the dest_net instead
>>>    of src_net, I can provide the patch.
>> *snip*
>>
>> As the author of the HSR driver, I'd like to answer this question, but unfortunately
>> I don't know what x-netns is. Neither Google nor Documentation/ has been particularly
>> helpful.
>>
>> Care to elaborate? (Maybe this is a moot point now that the patch has been accepted,
>> but I'd still like to understand, if you have the time to explain.)
> Basically, network namespaces (netns) allow you to run several independant
> instances of the linux networking stack.
> Network interfaces are bound to one netns. By default, only one netns exists
> (named init_net) when you boot your kernel.
> For logical interfaces, they are usually bound to a link layer. For example, if
> I understand well, hsr network interfaces receive and send their packets from
> two physical interfaces (IFLA_HSR_SLAVE[1|2]).
> Now imagine that these slaves are in a netns foo and the logical hsr interfaces
> in netns bar. You have a x-netns interface, the link layer part of the interface
> is not in the same netns than the upper part. A user will see the hsr interface
> in netns bar, but this interface will send a receive packet in netns foo.

Ok, so x-netns simply means cross-netns?

> Usually, to configure an interface like this, you create it in netns foo and you
> move it later to netns bar (ip link set hsr1 netns bar). The flag
> NETIF_F_NETNS_LOCAL forbids this operation, you cannot move it to another netns.
> But you still can create a x-netns interface:
> ip netns add foo
> ip link add hsr1 netns foo type hsr slave1 eth0 slave2 eth1
> ip netns exec foo ip link ls hsr1
> 
> => eth0 and eth1 are took from the current netns (because in the code, src_net
> is the current netns) but hsr1 is built in netns foo.
> 
> Now, the question is: does HSR really work across netns? Why is the flag
> NETIF_F_NETNS_LOCAL set?
> dev_forward_skb() may be used to forward an skbuff to another netns.

Here is the code snippet that sets NETIF_F_NETNS_LOCAL:
	/* Not sure about this. Taken from bridge code. netdev_features.h says
	 * it means "Does not change network namespaces".
	 */
	dev->features |= NETIF_F_NETNS_LOCAL;

HSR is a bit like a bridge since it forwards packets between interfaces on the 
same Ethernet network, and the bridge code sets NETIF_F_NETNS_LOCAL. And that's 
really all the reason for the inclusion of the flag - i.e. it should be removed
if it doesn't make sense.

So, does it make sense? I'm not sure exactly, but I don't think it makes sense
to have slaves that are in different namespaces - they are supposed to be part 
of the same ethernet network after all. But maybe having the HSR interface in a 
different namespace than the two slaves could make sense - this way you could 
force an application to only communicate using the HSR protocol, and not use any 
of the slave interfaces directly.

If you agree with the above, then I guess that means NETIF_F_NETNS_LOCAL should 
not be set?


> Note, that I got a panic when playing with hsr:
> ip link add hsr1 type hsr slave1 eth1 slave2 eth0
> ip link del hsr1
> => panic
> 
> I dig a bit:
> 1/ hsr_netdev_notify() supposes that the port will always be available when the
> notification is for an hsr interface. It's wrong. For example,
> netdev_wait_allrefs() may resend NETDEV_UNREGISTER.
> 2/ with a patch that ignores the notification when the port is NULL, I got a
> refcnt problem:
> [  327.372099] unregister_netdevice: waiting for hsr1 to become free. Usage count = -1

Thanks for the bug report! I'll take a look at it ASAP.


-- 
Arvid Brodin | Consultant (Linux)
ALTEN | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden
arvid.brodin@...en.se | www.alten.se/en/

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ