| 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
| ||
|
Date: Mon, 31 Aug 2009 17:12:51 -0700
From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org, gospo@...hat.com,
Dave Graham <david.graham@...el.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: [net-next PATCH] e1000: Fix for e1000 kills IPMI on a tagged vlan.
From: Graham, David <david.graham@...el.com>
Enabling VLAN filters (VFE) when the primary interface is brought up
(per commit 78ed11a) has caused problems for some users who manage
their systems using IPMI over a VLAN. This is because when the driver
enables the VLAN filter, this same filter table is enabled for the
management channel, and the table is initially empty, which means that
the IPMI/VLAN packets are filtered out and not received by the BMC.
This is a problem only on e1000 class adapters, as it is only
on e1000 that the filter table is common to the management and host
streams.
With this change, filtering is only enabled when one or more host VLANs
exist, and is disabled when the last host VLAN is removed. VLAN filtering
is always disabled when the primary interface is in promiscuous mode,
and will be (re)enabled if VLANs exist when the interface exits
promiscuous mode.
Note that this does not completely resolve the issue for those using VLAN
management, because if the host adds a VLAN, then the above problem
occurs when that VLAN is enabled. However, it does mean the there is no
problem for configurations where management is on a VLAN and the host is
not.
A complete solution to this issue would require further driver changes.
The driver would need to discover if (and which) management VLANs are
active before enabling VLAN filtering, so that it could ensure that the
managed VLANs are included in the VLAN filter table. This discovery
requires that the BMC identifies its VLAN in registers accessible
to the driver, and at least on Dell PE2850 systems the BMC does not
identify its VLAN to allow such discovery. Intel is pursuing this issue
with the BMC vendor.
Signed-off-by: Dave Graham <david.graham@...el.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
---
drivers/net/e1000/e1000_main.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index d7df00c..4bdbadc 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2401,7 +2401,9 @@ static void e1000_set_rx_mode(struct net_device *netdev)
rctl &= ~E1000_RCTL_MPE;
}
if (adapter->hw.mac_type != e1000_ich8lan)
- rctl |= E1000_RCTL_VFE;
+ /* Enable VLAN filter if there is a VLAN */
+ if (adapter->vlgrp)
+ rctl |= E1000_RCTL_VFE;
}
if (netdev->uc.count > rar_entries - 1) {
@@ -4854,6 +4856,8 @@ static void e1000_vlan_rx_register(struct net_device *netdev,
/* enable VLAN receive filtering */
rctl = er32(RCTL);
rctl &= ~E1000_RCTL_CFIEN;
+ if (!(netdev->flags & IFF_PROMISC))
+ rctl |= E1000_RCTL_VFE;
ew32(RCTL, rctl);
e1000_update_mng_vlan(adapter);
}
@@ -4864,6 +4868,11 @@ static void e1000_vlan_rx_register(struct net_device *netdev,
ew32(CTRL, ctrl);
if (adapter->hw.mac_type != e1000_ich8lan) {
+ /* disable VLAN receive filtering */
+ rctl = er32(RCTL);
+ rctl &= ~E1000_RCTL_VFE;
+ ew32(RCTL, rctl);
+
if (adapter->mng_vlan_id !=
(u16)E1000_MNG_VLAN_NONE) {
e1000_vlan_rx_kill_vid(netdev,
--
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