linux-kernel - Re: [PATCH] ath: sanitize 0xFFFF regdomain

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:	Tue, 26 Feb 2013 12:01:00 -0800
From:	"Luis R. Rodriguez" <mcgrof@....qualcomm.com>
To:	Michał Kazior <kazikcz@...il.com>
Cc:	David Quan <dquan@....qualcomm.com>, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org, Pavel Roskin <proski@....org>
Subject: Re: [PATCH] ath: sanitize 0xFFFF regdomain

On Tue, Feb 26, 2013 at 11:28 AM, Michał Kazior <kazikcz@...il.com> wrote:
> On 26 February 2013 19:29, Luis R. Rodriguez <mcgrof@....qualcomm.com> wrote:
>> NACK. This comes up every now and then and this is not a valid device
>> ID, this is an issue with the card, so what you can do is adjust the
>> device ID post bootup. Not sure if distros have an easy way to set
>> this up, if not perhaps this should be considered as this has come up
>> twice before.
>
> The erroneous 0xFFFF value comes from using one of eeprom_ops
> implementations.

Apologies I quickly read this as an issue with 0xFFFF device ID and
not a regulatory domain ID being set to 0xFFFF. Just to clarify for
the reader / record then given I may have mislead folks with my
comments -- the issue you are reporting is regarding an 0xFFFF
regulatory domain, not the PCI device ID being set to 0xFFFF (which
was also reported at times).

Given I NACK'd assuming this was a PCI device ID issue let me
elaborate on that possible issue for future's and record's sake and
also on your issue.

The eeprom_ops are a set of ops for different set of family of cards
we support. The correct eeprom_ops family of functions your card would
end up using will vary depending not only the PCI device ID to load
the driver but more importantly on the family ID on the EEPROM, see
ath9k_hw_eeprom_init() and ath9k_hw_read_revisions(), essentially
obtained through PCI iomem reads. If the EEPROM is messed up then the
wrong family of device would be set and there no point to support
these type of devices in kernel code, the way to work around these
issues would be at post load using sysfs, and that is why I jumped the
gun and NACKed thinking it was this type of issue.

In your case though you claim that only the EEPROM regulatory domain
is not being recognized as valid by the ath regd code, granted that
the driver does an EEPROM checksum check so if indeed that was the
intended EEPROM regd value programmed then the regd value was intended
to be that. Now, 0xFFFF is simply not a known regulatory domain that
we support and why it would be programmed as such is beyond me. It is
not something we support! Given that your card exists and likely
perhaps others (whoever programmed that card, not sure)... we can
indeed add support as you suggest by using the most restrictive world
regulatory domain as you have amended.

Apologies again and then (unless I hear otherwise from David Quan):

Acked-by: Luis R. Rodriguez <mcgrof@....qualcomm.com>

But please re-post and amend the commit log entry with information
that explain that given that your EEPROM must have been intentionally
programmed to 0xFFFF given that the EEPROM checksum is valid, but that
QCA does not support 0xFFFF as a valid regulatory domain value you are
adding support by using the 0x64 regulatory domain, the most
restrictive custom world regulatory domain by the ath module.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/