netdev - Re: [PATCH iwl-next v2 2/2] ice: Implement 'flow-type ether' rules

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] [day] [month] [year] [list]

Message-ID: <4bf80a63-868b-4ed6-9e73-ba79a1315bad@intel.com>
Date: Thu, 14 Dec 2023 09:19:23 +0100
From: "Plachno, Lukasz" <lukasz.plachno@...el.com>
To: Simon Horman <horms@...nel.org>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>, "Jakub
 Buchocki" <jakubx.buchocki@...el.com>, Mateusz Pacuszka
	<mateuszx.pacuszka@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH iwl-next v2 2/2] ice: Implement 'flow-type ether' rules

On 12/12/2023 11:29 AM, Simon Horman wrote:
> On Thu, Dec 07, 2023 at 01:48:40PM +0100, Lukasz Plachno wrote:
>> From: Jakub Buchocki <jakubx.buchocki@...el.com>
>>
>> Add support for 'flow-type ether' Flow Director rules via ethtool.
>>
>> Rules not containing masks are processed by the Flow Director,
>> and support the following set of input parameters in all combinations:
>> src, dst, proto, vlan-etype, vlan, action.
>>
>> It is possible to specify address mask in ethtool parameters but only
>> 00:00:00:00:00 and FF:FF:FF:FF:FF are valid.
>> The same applies to proto, vlan-etype and vlan masks:
>> only 0x0000 and 0xffff masks are valid.
>>
>> Signed-off-by: Jakub Buchocki <jakubx.buchocki@...el.com>
>> Co-developed-by: Mateusz Pacuszka <mateuszx.pacuszka@...el.com>
>> Signed-off-by: Mateusz Pacuszka <mateuszx.pacuszka@...el.com>
>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>> Signed-off-by: Lukasz Plachno <lukasz.plachno@...el.com>
> 
> ...
> 
>> @@ -1268,6 +1374,16 @@ ice_cfg_fdir_xtrct_seq(struct ice_pf *pf, struct ethtool_rx_flow_spec *fsp,
>>   		ret = ice_set_fdir_ip6_usr_seg(seg, &fsp->m_u.usr_ip6_spec,
>>   					       &perfect_filter);
>>   		break;
>> +	case ETHER_FLOW:
>> +		ret = ice_set_ether_flow_seg(seg, &fsp->m_u.ether_spec);
>> +		if (!ret && (fsp->m_ext.vlan_etype || fsp->m_ext.vlan_tci)) {
>> +			if (!ice_fdir_vlan_valid(fsp)) {
>> +				ret = -EINVAL;
>> +				break;
>> +			}
>> +			ret = ice_set_fdir_vlan_seg(seg, &fsp->m_ext);
>> +		}
>> +		break;
>>   	default:
>>   		ret = -EINVAL;
>>   	}
> 
> Hi Jakub,
> 
> A bit further down this function, perfect_filter is used as follows.
> 
> 	...
> 
> 	if (user && user->flex_fltr) {
> 		perfect_filter = false;
> 		...
> 	}
> 
> 	...
> 
> 	assign_bit(fltr_idx, hw->fdir_perfect_fltr, perfect_filter);
> 
> And unlike other non-error cases handled in the switch statement,
> the new ETHER_FLOW case does not set perfect_filter.
> 
> It's unclear to me if this is actually the case or not,
> but Smatch flags that perfect_filter may now be used uninitialised
> in the assign_bit() call above.
> 
> ...

Hi Simon,

Thank you for pointing that out, perfect_filter should be initialized to 
false, I will fix that in V3.

Thanks,
Łukasz