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:   Mon, 11 Jun 2018 09:50:48 +0900
From:   Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
To:     David Miller <davem@...emloft.net>, eladv6@...il.com
Cc:     Jose.Abreu@...opsys.com, f.fainelli@...il.com,
        netdev@...r.kernel.org, peppe.cavallaro@...com,
        alexandre.torgue@...com
Subject: Re: [PATCH v6 net] stmmac: strip all VLAN tag types when kernel
 802.1Q support is selected

On 2018/06/11 4:29, David Miller wrote:
> From: Elad Nachman <eladv6@...il.com>
> Date: Fri, 8 Jun 2018 12:19:29 +0300
> 
>> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before 
>> calling napi_gro_receive().
>>
>> The function assumes VLAN tagged frames are always tagged with 
>> 802.1Q protocol, and assigns ETH_P_8021Q to the skb by hard-coding
>> the parameter on call to __vlan_hwaccel_put_tag() .
>>
>> This causes packets not to be passed to the VLAN slave if it was created 
>> with 802.1AD protocol
>> (ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
>>
>> This fix passes the protocol from the VLAN header into 
>> __vlan_hwaccel_put_tag() instead of using the hard-coded value of
>> ETH_P_8021Q.
>>
>> NETIF_F_HW_VLAN_CTAG_RX check was removed and instead the strip action 
>> is dependent upon a preprocessor define which is defined when 802.1Q 
>> support is selected in the kernel config. 
>>
>> NETIF_F_HW_VLAN_STAG_RX feature was added to be in line with the driver 
>> actual abilities.
>>
>> Signed-off-by: Elad Nachman <eladn@...at.com>
> 
> You can't remove the NETIF_F_* checks.
> 
> If the user doesn't have VLAN offloading enabled, the VLAN tags should
> be left in the packet as-is.
> 
> It can't be controlled by a CPP check.

David, NETIF_F_HW_VALN_*_RX is not user-controllable in this driver
because hw_features does not include them.

But this can break when those features are added to hw_features so if
David does not like this situation I think we need the condition anyway.

-- 
Toshiaki Makita

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ