linux-kernel - Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN

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: <18219.26528.485099.317944@zeus.sw.starentnetworks.com>
Date:	Fri, 2 Nov 2007 14:08:32 -0400
From:	Dave Johnson <djohnson+linux-kernel@...starentnetworks.com>
To:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	bguo@...starentnetworks.com, Michael Chan <mchan@...adcom.com>
Subject: Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?

Dave Johnson writes:
> Ben Greear writes:
> > Currently, VLAN devices offer the ability to 'reorder' the header
> > and explicitly remove the VLAN header.  I assume we keep this
> > feature and have the AF_PACKET logic check the device flags to see
> > if it should insert the VLAN header for hw-accel vlans? 
> > 
> > Either way, if we sniff the underlying device, we should always get
> > the VLAN header.
> 
> Yes, but it's more than just a packet socket issue.
> 
> A quick look through the hwaccel capable drivers (in 2.6.23) and most
> are doing something like:
> 
> if (foo->vlgrp && packet_is_tagged)
>   vlan_hwaccel_receive_skb(skb, foo->vlgrp, vlan_tag);
> else
>   netif_receive_skb(skb);
> 
> The important thing here is if the vlan group is NULL, the MAC must
> be configured to NOT strip the tag.
> 
> users of NETIF_F_HW_VLAN_RX:
> ---------------------------
> ./drivers/net/8139cp.c:             looks ok
> ./drivers/net/acenic.c:             *1
> ./drivers/net/amd8111e.c:           unsure, probably *1
> ./drivers/net/atl1/atl1_main.c:     looks ok
> ./drivers/net/bnx2.c:               *2
> ./drivers/net/bonding/bond_main.c:  unsure, probably ok
> ./drivers/net/chelsio/cxgb2.c:      looks ok
> ./drivers/net/cxgb3/cxgb3_main.c:   looks ok
> ./drivers/net/e1000/e1000_main.c:   looks ok
> ./drivers/net/ehea/ehea_main.c:     unsure, probably ok
> ./drivers/net/forcedeth.c:          looks ok
> ./drivers/net/gianfar.c:            looks ok
> ./drivers/net/ixgb/ixgb_main.c:     looks ok
> ./drivers/net/ns83820.c:            unsure, probably ok
> ./drivers/net/r8169.c:              looks ok
> ./drivers/net/s2io.c:               *1
> ./drivers/net/sky2.c:               looks ok
> ./drivers/net/starfire.c:           unsure, probably ok
> ./drivers/net/tg3.c:                *2
> ./drivers/net/typhoon.c:            unsure, probably ok
> ./drivers/s390/net/qeth_main.c:     unsure, probably ok
> 
> *1:  Driver configures the MAC to strip TAGs even if vlan group is
>      NULL. MAC strips the tag, but driver calls netif_rx() or
>      netif_receive_skb() with the packet as untagged.  Kernel
>      processes tagged packet as if it was received untagged.  Possible
>      security issue.
> 
> *2:  If chip supports 'ASF', tag is always stripped (see *1 above).
>      Looks ok if ASF is not supported. 

Michael,

These changes seems to cause this issue:

>  [BNX2]: Fix VLAN on ASF
>  
>  Always set up the device to strip incoming VLAN tags when ASF is
>  enabled. ASF firmware will not parse packets correctly if VLAN tags
>  are not stripped.
>  
>  Signed-off-by: Michael Chan <mchan@...adcom.com>
>  Signed-off-by: David S. Miller <davem@...emloft.net>
>  
>  GIT: e29054f92d7d575631691865c1b95bee5bc974cc

and

> ChangeSet@...371.72.2, 2003-12-02 02:34:13-08:00, davem@...s.ninka.net +1 -0
>   [TG3]: Do not set RX_MODE_KEEP_VLAN_TAG when ASF is enabled.


Could you elaborate if this is really needed, if so is there some
workaround that could be done instead?

Simply removing the check seemed to work for me, but I'm unsure if
this is actually a valid thing to do with these MACs.



-- 
Dave Johnson
Starent Networks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/