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, 18 Nov 2009 16:33:27 -0700
From:	"Williams, Mitch A" <mitch.a.williams@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing
	hardware queue MAC and VLAN filters

>From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>Sent: Wednesday, November 18, 2009 3:14 PM
>> Setting a MAC filter doesn't blow away the VLAN filter, or vice-versa. So
>just run 'ip' twice to set the filters. Our hardware does it too, and it
>works fine for me:
>>
>> $ ip link set eth1 queue 1 mac 00:11:22:33:44:55
>> $ ip link set eth1 queue 1 vlan 10
>
>Hmm, this is not what I would expect.  I'm used to filters being defined
>independently of queues in a hash table or CAM.  In that case, setting
>multiple filters pointing to one queue will result in the logical
>disjunction of the filters.  Do I understand correctly that you have
>exactly one of each type of filter per queue, with multiple filters
>interpreted as a logical conjunction?
>

Well, it's weirder than that.

In the case of SR-IOV on our hardware, these filters are perfect - no hash tables are required. (We do use hash tables when we have a bunch of multicast addresses, but that's not what this is about.)

MAC filters deny packets by default, so you won't get anything without a valid MAC filter on the queue.

A queue with no VLAN filters will receive packets from all VLANs, albeit with the tags passed up intact.  So in that sense, the VLAN filters are default-allow.  

However, once you enable any VLAN filter, the hardware starts stripping tags and begins to deny packets by default.

Based on these semantics, the filtering operation that I've described above makes perfect sense.

If I understand you correctly, you'd like to be able to apply both types of filter on a single command line:

$ip link set eth1 queue 1 mac <something> vlan <something>

Obviously, this can be done, but it would complicate the code significantly.

-Mitch
--
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