netdev - Re: [PATCH #2] [8021Q]: Turn off all the hardware VLAN features for promisc

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] [day] [month] [year] [list]

Date:	Fri, 21 Mar 2008 01:46:02 +0900
From:	"Joonwoo Park" <joonwpark81@...il.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH #2] [8021Q]: Turn off all the hardware VLAN features for promisc

2008/3/20, Patrick McHardy <kaber@...sh.net>:
>
> I think a better way to handle this would be to make packet
> sockets understand VLAN accerlation, similar to partial
> checksums. This would mean on TX we get the tag from the
> packets meta data and put it in the auxillary data.
> RX should probably be handled by the driver by disabling
> VLAN filtering when promiscous mode is enabled.
>
> VLAN stripping would currently also have to be disabled,
> but since its necessary to move the tag from the CB
> to the skb anyways for avoiding qdiscs trampling over
> it, once we've done that we could keep stripping enabled
> and also store the VID on RX and make it visible to
> packet sockets.
>
> This would require to teach userspace about the new
> auxillary data, but allows to use tcpdump and vlan
> accerlation at the same time and doesn't require to
> disabling accerlation when going to promiscous mode
> for other reasons (like secondary unicast addresses).
>

Thanks Patrick for reviewing this and show me the better way.

To summarize your say, disable VLAN filtering by driver handling and
push new auxillary data to packet socket for RX & TX. Right?

Actually for the VLAN filtering, It seemed possible to disable it
without fixing every driver codes relatively easily, but for now it
might not be a proper way I think.
Also I did concern a situation 'promiscuous without tcpdump' like
secondary unicast addresses.
I think the opinion that you said is the solution.
Thanks again.
I'll try these things.

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