linux-kernel - Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

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]

Message-ID: <CA+ASDXNx30A3=BA9b-tiAQzYHP=nV_eLw1QFpJij=F=JgWZ5sg@mail.gmail.com>
Date:   Tue, 30 Aug 2022 14:56:51 -0700
From:   Brian Norris <briannorris@...omium.org>
To:     Cale Collins <ccollins@...eworks.com>
Cc:     kvalo@...nel.org, Patrick Steinhardt <ps@....im>,
        ath10k <ath10k@...ts.infradead.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Tim Harvey <tharvey@...eworks.com>,
        Stephen McCarthy <stephen.mccarthy@...el.com>
Subject: Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

Hi Cale,

I meant to respond a while back, but didn't get around to it, sorry.
In case it's still helpful:

On Wed, May 11, 2022 at 3:52 PM Cale Collins <ccollins@...eworks.com> wrote:
> On Mon, May 9, 2022 at 11:16 AM Cale Collins <ccollins@...eworks.com> wrote:
> > I'm experiencing an issue very similar to this.  The regulatory domain
> > settings wouldn't allow me to create an AP on 5ghz bands on kernels
> > newer than 5.10 when using a WLE900VX (QCA9984) radio.  I bisected the
> > kernel and ultimately landed on the regression that Brian patched.

If the revert broke you, then you were also broken before v5.6. This
patch only landed in v5.6-rc1:

2dc016599cfa ath: add support for special 0x0 regulatory domain

I'm not really an expert on the wide variety of ath-related hardware
production, but given the many people complaining about the existence
of the non-reverted patch, it seemed like a revert was the best way
forward -- don't break those that weren't already broken pre-5.6.

> > root@...al-ventana:~# iw reg get
> > global
> > country 00: DFS-UNSET
> >     (2402 - 2472 @ 40), (N/A, 20), (N/A)
> >     (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR
> >     (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
> >     (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR
> >     (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR
> >     (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> >     (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> >     (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> >
> > phy#0
> > country 99: DFS-UNSET
> >     (2402 - 2472 @ 40), (N/A, 20), (N/A)
> >     (5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
> >     (5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN

Unless there's some other bug hidden in here in how we're reading
EEPROM settings, it sounds like you have a badly-provisioned PCI
module, with no EEPROM country code. Thus, the driver has to
conservatively treat you as a very-limited "world roaming" regulatory
class, which mostly disables 5GHz, or at least doesn't let you
initiate much radiation on your own (which basically eliminates AP
mode).

The "fix" there would be to get a different, correctly-provisioned
(for your regulatory domain) module.

Also, I didn't notice until today: technically, you also could be
retrieving your incorrect country code info from ACPI; but if you're
using a typical ARM board like claimed, it's unlikely you're using
ACPI.

Somewhat of a sidetrack: The existence of ACPI override support does
suggest that perhaps there's some room for a Device Tree property, so
one can set their regulatory domain on a per-board basis. I've
definitely known some downstream product makers use that sort of
approach -- and that very "solution" is potentially why some devices
don't get a valid EEPROM (if the manufacturer could hack the drivers,
why bother getting the EEPROM right?), and therefore don't work
correctly with upstream kernels... Unfortunately, that kind of
solution is hard to deploy 100% correctly for upstream Linux, because
the Device Tree would need to change depending on which country the
affected system is shipped to. It's easier to get those things right
in a pre-flashed firmware or an EEPROM; it's harder to get those in a
software DTS file shipped to everyone in the mainline kernel sources.

> > #dmesg |grep ath output

In the slim chance there's something else going on in the driver, you
might try to capture logs with ATH10K_DBG_BOOT and
ATH10K_DBG_REGULATORY logging enabled. That could look something like:

echo 0x820 > /sys/module/ath10k_core/parameters/debug_mask
rmmod ath10k_pci
modprobe ath10k_pci
dmesg | grep ath

Brian