netdev - RE: [PATCH net-next 1/2] cxgb4/cxgb4vf: Add support for ndo_set_vf

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Aug 2016 08:31:58 +0000
From:   Yuval Mintz <Yuval.Mintz@...gic.com>
To:     Hariprasad Shenai <hariprasad@...lsio.com>
CC:     netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        "leedom@...lsio.com" <leedom@...lsio.com>,
        "nirranjan@...lsio.com" <nirranjan@...lsio.com>
Subject: RE: [PATCH net-next 1/2] cxgb4/cxgb4vf: Add support for
 ndo_set_vf_vlan

> > > @@ -1202,6 +1202,10 @@ int t4vf_eth_xmit(struct sk_buff *skb, struct
> > > net_device *dev)
> > >  	BUG_ON(qidx >= pi->nqsets);
> > >  	txq = &adapter->sge.ethtxq[pi->first_qset + qidx];
> > >
> > > +	if (pi->vlan_id && !skb_vlan_tag_present(skb))
> > > +		__vlan_hwaccel_put_tag(skb, cpu_to_be16(ETH_P_8021Q),
> > > +				       pi->vlan_id);
> > > +
> >
> > So it's a purely SW implementation of the feature on the VF side?
> > Does the HW enforces the configuration in any way on the VF?
> Basically the PF driver passes the VLAN ID it got through ndo_set_vf_vlan to the
> VF driver. And then the VF driver reads it and requests hardware to tag it.

Problem with SW implementations is mainly that they have no effect over
Malicious VFs
 I.e., if the purpose here is to add the VF to some vlan-tagged subnet
Whereas the user is oblivious to it, a malicious user can easily modify
the driver to ignore this restriction and get access to the entire network.

I think one of the problems with this ndo is that it's poorly documented
and thus open for various interpretations - so it's debatable what's important
and what's not. [If it is properly documented anywhere, please educate me]

> > Also, looks like an already tagged packet would be processed with the
> > original vlan-id [instead of the one of PF has provided].
> > Is that intentional?
> No, this isn't intentional. I thought VST and VGT cannot co-exist.
> What should be the behavior?

Are you preventing VGT configuration once VST is configured?
If not, what to prevent VM user from configuring vlan interfaces
on top of the VF, even if VST is configured?