netdev - Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

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: <1392108205.22033.16.camel@dagon.hellion.org.uk>
Date:	Tue, 11 Feb 2014 08:43:25 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
CC:	<netdev@...r.kernel.org>, <xen-devel@...ts.xenproject.org>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Paul Durrant <Paul.Durrant@...rix.com>,
	"Wei Liu" <wei.liu2@...rix.com>
Subject: Re: [RFC 2/2] xen-netback: disable multicast and use a random hw
 MAC address

On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@...e.com>
> 
> Although the xen-netback interfaces do not participate in the
> link as a typical Ethernet device interfaces for them are
> still required under the current archtitecture. IPv6 addresses
> do not need to be created or assigned on the xen-netback interfaces
> however, even if the frontend devices do need them, so clear the
> multicast flag to ensure the net core does not initiate IPv6
> Stateless Address Autoconfiguration.

How does disabling SAA flow from the absence of multicast? Surely these
should be controlled logically independently even if there is some
notional linkage. Can SAA not be disabled directly?

>  Clearing the multicast
> flag is required given that the net_device is using the
> ether_setup() helper.
> 
> There's also no good reason why the special MAC address of
> FE:FF:FF:FF:FF:FF is being used other than to avoid issues
> with STP,

With your change there is a random probability on reboot that the bridge
will end up with a randomly generated MAC address instead of a static
MAC address (usually that of the physical NIC on the bridge), since the
bridge tends to inherit the lowest MAC of any port.

Since IP configuration is done on the bridge this will break DHCP,
whether it is using static or dynamic mappings from MAC to IP address,
and the host will randomly change IP address on reboot.

So Nack for that reason.

>  since using this can create an issue if a user
> decides to enable multicast on the backend interfaces

Please explain what this issue is.

Also how can a user enable multicast on the b/e? AFAIK only Solaris ever
implemented the m/c bits of the Xen PV network protocol (not that I
wouldn't welcome attempts to add it to other platforms)

Ian.

--
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