linux-kernel - Re: [PATCH v2 0/3] hwmon: (nct6775) Support lock by ACPI mutex

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, 17 Dec 2021 08:22:58 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Denis Pauk <pauk.denis@...il.com>
Cc:     eugene.shalygin@...il.com, andy.shevchenko@...il.com,
        platform-driver-x86@...r.kernel.org,
        Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] hwmon: (nct6775) Support lock by ACPI mutex

On 12/16/21 2:22 PM, Denis Pauk wrote:
> Hi,
> 
> Could you please provide a some feedback about such idea?
> 
> I have bigger list of supported boards that requires ACPI mutex lock,
> but I prefer to have some feedback before send next version of patch.
> 
> I have created separate patch[1] with only boards where WMI methods is
> enough. And if work on patch takes some time/additional patch
> versions(for sure it will), I prefer to have that patch merged and
> rebase current patch over resulted list of boards.
> 

Looking through the code, I am absolutely not happy with it. It makes
the driver even more unreadable than it already is, and on top of that
makes it vulnerable to problems in the ACPI code. Example: If ACPI fails
to unlock the mutex, the driver will end up being non-functional.

At some point, we have to face it: ASUS doesn't support Linux, and they
make it hard to access chips like this. I think the chip should be
accessed through "official" channels only if provided (ie WMI/ACPI),
or not at all.

Guenter