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] [day] [month] [year] [list]
Date: Sat, 11 May 2024 17:38:10 +0100
From: Simon Horman <horms@...nel.org>
To: Larysa Zaremba <larysa.zaremba@...el.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
	intel-wired-lan@...ts.osuosl.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, alan.brady@...el.com,
	maciej.fijalkowski@...el.com, jesse.brandeburg@...el.com,
	Emil Tantilov <emil.s.tantilov@...el.com>,
	Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
	joshua.a.hay@...el.com,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Igor Bagnucki <igor.bagnucki@...el.com>
Subject: Re: [PATCH iwl-net] idpf: Interpret .set_channels() input differently

On Fri, Apr 26, 2024 at 05:41:22PM +0200, Larysa Zaremba wrote:
> Unlike ice, idpf does not check, if user has requested at least 1 combined
> channel. Instead, it relies on a check in the core code. Unfortunately, the
> check does not trigger for us because of the hacky .set_channels()
> interpretation logic that is not consistent with the core code.
> 
> This naturally leads to user being able to trigger a crash with an invalid
> input. This is how:
> 
> 1. ethtool -l <IFNAME> -> combined: 40
> 2. ethtool -L <IFNAME> rx 0 tx 0
>    combined number is not specified, so command becomes {rx_count = 0,
>    tx_count = 0, combined_count = 40}.
> 3. ethnl_set_channels checks, if there is at least 1 RX and 1 TX channel,
>    comparing (combined_count + rx_count) and (combined_count + tx_count)
>    to zero. Obviously, (40 + 0) is greater than zero, so the core code
>    deems the input OK.
> 4. idpf interprets `rx 0 tx 0` as 0 channels and tries to proceed with such
>    configuration.
> 
> The issue has to be solved fundamentally, as current logic is also known to
> cause AF_XDP problems in ice [0].
> 
> Interpret the command in a way that is more consistent with ethtool
> manual [1] (--show-channels and --set-channels) and new ice logic.
> 
> Considering that in the idpf driver only the difference between RX and TX
> queues forms dedicated channels, change the correct way to set number of
> channels to:
> 
> ethtool -L <IFNAME> combined 10 /* For symmetric queues */
> ethtool -L <IFNAME> combined 8 tx 2 rx 0 /* For asymmetric queues */
> 
> [0] https://lore.kernel.org/netdev/20240418095857.2827-1-larysa.zaremba@intel.com/
> [1] https://man7.org/linux/man-pages/man8/ethtool.8.html
> 
> Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks")
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Reviewed-by: Igor Bagnucki <igor.bagnucki@...el.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@...el.com>

Reviewed-by: Simon Horman <horms@...nel.org>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ