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-next>] [day] [month] [year] [list]
Date:	Mon, 26 Sep 2011 15:36:30 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	netdev@...r.kernel.org
Subject: [RFC]  bridge: handle bridge group address per 802.1 standards

The Linux bridge code would process all packets addressed to
the multicast address 01:80:C2:00:00:0X as local and
and never forward. This may have been correct in the ancient past, but
reading the relevant standards, the correct behavior is to handle only
the bridge group address as a special case and leave all other link
local multicast packets alone.

Recently there has been some complaints about forwarding (or not) of
802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the 
802.1 Bridging Working Group for point me in the correct direction.
The 802.1X-2010 standard Table 11-1 details how different
addresses are assigned based on connectivity associations.
      
  Bridge group address:		01-80-C2-00-00-00
  PAE group address:            01-80-C2-00-00-03
  Link Layer Discovery          01-80-C2-00-00-0E

Warning: this may mean that some people using bridge who expect
link local packets to be isolated, now need to add firewall rules.
But in my opinion, following the standard is the correct thing to
do regardless.

This means when using 802.1x with libvirt, there are several options:
  1. Use macvtap not bridge
  2. Turn off STP in libvirt
  3. Use PAE group address for 802.1x
  4. Provide a user level application using AF_LLC to forward
     the 802.2 frames

Signed-off-by: Stephen Hemminger <shemminger@...tta.com>

--- a/net/bridge/br_input.c	2011-09-16 13:12:58.061369744 -0700
+++ b/net/bridge/br_input.c	2011-09-26 11:57:41.724554692 -0700
@@ -126,18 +126,6 @@ static int br_handle_local_finish(struct
 	return 0;	 /* process further */
 }
 
-/* Does address match the link local multicast address.
- * 01:80:c2:00:00:0X
- */
-static inline int is_link_local(const unsigned char *dest)
-{
-	__be16 *a = (__be16 *)dest;
-	static const __be16 *b = (const __be16 *)br_group_address;
-	static const __be16 m = cpu_to_be16(0xfff0);
-
-	return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0;
-}
-
 /*
  * Return NULL if skb is handled
  * note: already called with rcu_read_lock
@@ -161,13 +149,10 @@ rx_handler_result_t br_handle_frame(stru
 
 	p = br_port_get_rcu(skb->dev);
 
-	if (unlikely(is_link_local(dest))) {
-		/* Pause frames shouldn't be passed up by driver anyway */
-		if (skb->protocol == htons(ETH_P_PAUSE))
-			goto drop;
-
-		/* If STP is turned off, then forward */
-		if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
+	/* Special handling for bridge group address */
+	if (unlikely(compare_ether_addr(dest, br_group_address) == 0)) {
+		/* If STP is turned off, then act like a hub. */
+		if (p->br->stp_enabled == BR_NO_STP)
 			goto forward;
 
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
--
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