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

Date:	Wed, 31 Oct 2007 18:31:10 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
CC:	Dave Johnson <djohnson+linux-kernel@...starentnetworks.com>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Bin Guo <bguo@...starentnetworks.com>
Subject: Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?

Stephen Hemminger wrote:
>
> The code in AF_PACKET should fix the skb before passing to user space 
> so that there is
> no difference between accel and non-accel hardware.  Internal choices 
> shouldn't
> leak to user space.  Ditto, the receive checksum offload should be 
> fixed up as well.
Ok, I guess that will fix the sniffing issues and any user-space 
bridging type applications.

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.

What about drivers and filtering VLANs?  It seems there is still a 
difference between software
vlans and hw-accel in this case.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com> 
Candela Technologies Inc  http://www.candelatech.com

-
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