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>] [day] [month] [year] [list]
Message-ID: <38b2af4a43df2c6323c747d690ae6b713afa3cb8.camel@posteo.de>
Date:   Tue, 22 Aug 2023 08:15:49 +0000
From:   Michael Lugmair <michael.lugmair@...teo.de>
To:     linux-kernel@...r.kernel.org
Subject: [iwlwifi] - problems with device list loop and Intel Killer AX1650
 cards

Hello,

I am currently debugging why my Intel Killer AX1650 card is visible as
Intel AX203 in dmesg. This might be related to a problem that possibly
the wrong ucode is loaded.

[    1.849586] iwlwifi 0000:00:14.3: loaded firmware version
66.f1c864e0.0 QuZ-a0-hr-b0-66.ucode op_mode iwlmvm
[    2.092309] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX203,
REV=0x354


With some debug output added to `drv.c`, I found out that my card is
actually {0x43F0, 0x1651} (this one here [1]). But this block is not
even considered when looking for the correct card.

IWL_DEV_INFO(0x43F0, 0x1651, killer1650s_2ax_cfg_qu_b0_hr_b0,
iwl_ax201_killer_1650s_name)


Instead, the following block is chosen for my card [2]:
_IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY,
  IWL_CFG_MAC_TYPE_QUZ, SILICON_B_STEP,
  IWL_CFG_RF_TYPE_HR2, IWL_CFG_ANY, IWL_CFG_ANY,
  IWL_CFG_NO_160, IWL_CFG_ANY, IWL_CFG_NO_CDB,
  IWL_CFG_ANY,iwl_cfg_quz_a0_hr_b0, iwl_ax203_name)


The reason is that we are running backwards through the list of device
info blocks [3]. This leads to the behavior that we prefer the generic
entries over the specific ones. Generic entries have IWL_CFG_ANY for
device id and subdevice id. The specific ones have a dedicated number.

There was a refactoring once [4]. Before the refactoring we went
forward through the list. If a matching entry was found, we continued
to look for a "better" (more generic) entry instead of calling break,
so basically same behavior.

I can hardly believe that this is intended behavior. Can somebody
explain that to me?

Thanks in advance.

Best regards
Michael

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/intel/iwlwifi/pcie/drv.c?h=linux-6.4.y#n570
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/intel/iwlwifi/pcie/drv.c?h=linux-6.4.y#n1001
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/intel/iwlwifi/pcie/drv.c?h=linux-6.4.y#n1538
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/wireless/intel/iwlwifi/pcie/drv.c?h=v6.4.9&id=0a1f96d571c841b31d12d3697f149ae1ea3087ea

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ