netdev - RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier

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: <8A71B368A89016469F72CD08050AD334091C1FCF@maui.asicdesigners.com>
Date:	Wed, 2 Mar 2011 12:03:12 -0800
From:	"Dimitrios Michailidis" <dm@...lsio.com>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"Alexander Duyck" <alexander.duyck@...il.com>,
	"Alexander Duyck" <alexander.h.duyck@...el.com>,
	<davem@...emloft.net>, <jeffrey.t.kirsher@...el.com>,
	<netdev@...r.kernel.org>
Subject: RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier

Ben Hutchings wrote:
> On Wed, 2011-03-02 at 11:11 -0800, Dimitrios Michailidis wrote:
> > Ben Hutchings wrote:
> > > /**
> > >  * struct ethtool_flow_ext - flow spec common extension fields
> > >  * @vlan_etype: EtherType for vlan tagged packet to match
> > >  * @vlan_tci: VLAN tag to match
> > >  * @data: Driver-dependent data to match
> > >  *
> > >  * Note: Additional fields may be inserted before @vlan_etype in future,
> > >  * but the offset of the existing fields within the containing structure
> > >  * (&struct ethtool_rx_flow_spec) will be stable.
> > >  */
> > > struct ethtool_flow_ext {
> > > 	__be16	vlan_etype;
> > > 	__be16	vlan_tci;
> > > 	__be32	data[2];
> > > };
> >
> > I am wondering about the semantics of these vlan_* fields.  Is vlan_etype the
> > Ethertype in the VLAN header or the type after it?
> 
> It would be the the type in the VLAN tag.  The nested ethertype is
> normally implied by flow_type to be ETH_P_IP.
> 
> This does leave the question of what this would mean:
> 
> struct ethtool_rx_flow_spec fs = {
> 	.flow_type = ... | FLOW_EXT,
> 	...
> 	.h_ext.vlan_tci = htons(0x1234),
> 	.m_ext.vlan_etype = 0xffff,
> };
> 
> This says the TCI must be == 0x1234 but the type can be anything.  But
> the type surely has to be be one assigned for use in VLAN tags.  Should
> we leave it to the driver/hardware to determine what those valid types
> are, or should we reject this as valid?

Right.  Devices have some internal rules for what qualifies as a VLAN frame.
If users are given the option to specify vlan_etype what do they get?
At least we need to specify what is expected so drivers can decide if they can support it.