| 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: Wed, 30 Nov 2011 09:34:21 -0800
From: Greg Rose <gregory.v.rose@...el.com>
To: Ben Hutchings <bhutchings@...arflare.com>
CC: Roopa Prabhu <roprabhu@...co.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"chrisw@...hat.com" <chrisw@...hat.com>,
"sri@...ibm.com" <sri@...ibm.com>,
"dragos.tatulea@...il.com" <dragos.tatulea@...il.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>, "mst@...hat.com" <mst@...hat.com>,
"mchan@...adcom.com" <mchan@...adcom.com>,
"dwang2@...co.com" <dwang2@...co.com>,
"shemminger@...tta.com" <shemminger@...tta.com>,
"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
"kaber@...sh.net" <kaber@...sh.net>,
"benve@...co.com" <benve@...co.com>
Subject: Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support
for passthru mode
On 11/29/2011 9:19 AM, Ben Hutchings wrote:
> On Tue, 2011-11-29 at 16:35 +0000, Ben Hutchings wrote:
>>
>> Maybe I missed something!
>>
>> Let's be clear on what our models are for filtering. At the moment we
>> have MAC filters set through ndo_set_rx_mode and VF filters set through
>> ndo_set_vf_{mac,vlan}.
>>
>> Ignoring anti-spoofing for the moment, should the currently defined
>> filters look like this (a):
>>
>> TX ^ | RX
>> | v
>> +------------------+---+-----------------+
>> | | ++------------+ |
>> | | |RX MAC filter| |
>> | | ++------------+ |
>> | | |match |
>> | ^ v |
>> | | ++------------+ |
>> | | |RX VF filters| |
>> | | +-------+-----+ |
>> | /|\ no /|\ |
>> | | | \ match/ | |match 2 |
>> | | ^ \ / v | |
>> | | | \ /match| |
>> | | \ \/ 1/ | |
>> | | \ /\ / | |
>> | ^ \/ \/ v |
>> | | /\ /\ | |
>> | | / || \ | |
>> | | / || \ | |
>> | | / || \ | |
>> | || || || |
>> +----------------++-----++-----++--------+
>> || || ||
>> PF VF 1 VF 2
>>
>> or like this (b):
>>
>> TX ^ | RX
>> | v
>> +------------------+---+-----------------+
>> | | ++------------+ |
>> | | |RX VF filters| |
>> | | ++--------+---+ |
>> | | no|match /| |
>> | ^ v | | |
>> | | +-+----+ | | |
>> | | |RX MAC| | | |
>> | | |filter| | | |
>> | | +------+ | | |
>> | | |match | | |
>> | /|\ | | | |
>> | | | \ | match| |match 2 |
>> | | ^ \/ 1 v | |
>> | | | /\ | | |
>> | | \/ \ / | |
>> | | /\ \ / | |
>> | ^ / \ \/ v |
>> | || \ /\ | |
>> | || || \ | |
>> | || || \ | |
>> | || || \ | |
>> | || || || |
>> +----------------++-----++-----++--------+
>> || || ||
>> PF VF 1 VF 2
>>
>> I think the current model is (a); do you agree?
>>
>> So is the proposed new model something like this (c):
>
> Corrected diagram:
>
> TX ^ | RX
> | v
> +------------------+---+-----------------+
> | | ++------------+ |
> | | |RX MAC filter| |
> | ^ ++------------+ |
> | | |match |
> | no match| v |
> | +----------------+ ++------------+ |
> | |loopback filters| |RX VF filters| |
> | +---------+-----++ +-------+-----+ |
> | /|\ /|\ match /|\ |
> | v | `-+>+-+-.2 / | | |
> | \ \ | |m \ \ / | | |
> | match 0\ `-+-+.a \ \ / v | |
> | \ | | \t \ X / | |
> | \ | \ \c X \ / | |
> | \| \ \h \ X | |
> | \ \/\1 X \ v |
> | || /\ |/ \ \ | |
> | |v / || \ \| |
> | || / ^| \ | |
> | ||/ |v || |
> | || || || |
> +----------------++-----++-----++--------+
> || || ||
> PF VF 1 VF 2
>
>> (I've labelled the new filters as loopback filters here, and I'm still
>> leaving out anti-spoofing.)
>>
>> If not, please explain what the new model *is*.
The new model is to incorporate a VEB into the NIC. The current model
doesn't address any of the requirements of a VEB in the NIC and this
proposed set of patches allow us to set MAC filters for the *ports* on
the internal NIC VEB. Consider the PF and each of the VFs as just a
port on the VEB. We need the ability to set L2 filters (MAC, MC and
VLAN) for each of the ports on that VEB. There is no currently
supported method for doing this. So yes, this is a new model although
it's a fairly simple one.
If you have an alternative proposal for allowing us to set L2 filters
for the ports on our NIC VEB then I'm all ears (or eyes as the case may be).
- Greg
--
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