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:   Fri, 6 Jan 2023 09:37:55 -0600
From:   Dave Chiluk <chiluk@...ntu.com>
To:     "Greenman, Gregory" <gregory.greenman@...el.com>
Cc:     "Coelho, Luciano" <luciano.coelho@...el.com>,
        "regressions@...mhuis.info" <regressions@...mhuis.info>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "marcel@...tmann.org" <marcel@...tmann.org>
Subject: Re: [regression] Bug 216753 - 6e 6 ghz bands are disabled since 5.16
 on intel ax211

On Thu, Jan 5, 2023 at 12:15 AM Greenman, Gregory
<gregory.greenman@...el.com> wrote:
>
> I'll try to explain, the problem here is not technical. After some
> internal checks, it appears that we (wifi driver) aren't allowed to
> decide if 6E should be enabled or not. Because of the legal restrictions,
> OEM should make this decision and enable/disable 6E in the BIOS. This
> commit only gets the value from the BIOS and configures the firmware
> accordingly. So, unfortunately, legal restriction is the reason we cannot
> revert/overwrite 6E enablement...
>
Thank you Gregory, I've been reading between the lines, and this is
pretty much what I expected you to say.  So in the past when
OEMs/systems manufacturers have been irresponsible/inept like this we
have implemented flags to force ignore the values coming out of the
bios.  As it's now obvious that the problem here is a legal/regulatory
issue, I'd hope that having a force flag would be acceptable from a
that perspective.  I'm no lawyer, but I expect once a user decides to
explicitly set a force flag to ignore the bios values I'd suspect the
responsibility would shift from the manufacturers and back onto the
user.

Would such a patch be theoretically acceptable?  If so I'll write up a
patch to do this and submit it next week hopefully.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ