netdev - [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: <1392071391-13215-3-git-send-email-mcgrof@do-not-panic.com>
Date:	Mon, 10 Feb 2014 14:29:51 -0800
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	netdev@...r.kernel.org
Cc:	xen-devel@...ts.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Paul Durrant <Paul.Durrant@...rix.com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Wei Liu <wei.liu2@...rix.com>
Subject: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address

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. 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, since using this can create an issue if a user
decides to enable multicast on the backend interfaces simply
use a random MAC address with the xen OUI prefix as is done
with the frontend through xen udev scripts.

Cc: Paul Durrant <Paul.Durrant@...rix.com>
Cc: Ian Campbell <ian.campbell@...rix.com>
Cc: Wei Liu <wei.liu2@...rix.com>
Cc: xen-devel@...ts.xenproject.org
Cc: netdev@...r.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
---
 drivers/net/xen-netback/interface.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b9de31e..479fbd1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -42,6 +42,8 @@
 #define XENVIF_QUEUE_LENGTH 32
 #define XENVIF_NAPI_WEIGHT  64
 
+static const u8 xen_oui[3] = { 0x00, 0x16, 0x3e };
+
 int xenvif_schedulable(struct xenvif *vif)
 {
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
@@ -347,15 +349,9 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	for (i = 0; i < MAX_PENDING_REQS; i++)
 		vif->mmap_pages[i] = NULL;
 
-	/*
-	 * Initialise a dummy MAC address. We choose the numerically
-	 * largest non-broadcast address to prevent the address getting
-	 * stolen by an Ethernet bridge for STP purposes.
-	 * (FE:FF:FF:FF:FF:FF)
-	 */
-	memset(dev->dev_addr, 0xFF, ETH_ALEN);
-	dev->dev_addr[0] &= ~0x01;
-
+	eth_hw_addr_random(dev);
+	memcpy(dev->dev_addr, xen_oui, 3);
+	dev->flags &= ~IFF_MULTICAST;
 	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
 
 	netif_carrier_off(dev);
-- 
1.8.5.3

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