linux-kernel - Re: [PATCH v2] watchdog: add in watchdog for nct6686

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]

Message-ID: <e6d0fda7-09db-4955-92dd-def2df768da6@roeck-us.net>
Date: Sat, 24 Feb 2024 08:19:27 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Mark Pearson <mpearson-lenovo@...ebb.ca>, David Ober
 <dober6023@...il.com>, wim@...ux-watchdog.org
Cc: linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org,
 David Ober <dober@...ovo.com>
Subject: Re: [PATCH v2] watchdog: add in watchdog for nct6686

On 2/23/24 11:49, Mark Pearson wrote:
> Hi,
> 
> On Tue, Dec 19, 2023, at 3:05 PM, Mark Pearson wrote:
>> On Tue, Sep 12, 2023, at 7:27 AM, David Ober wrote:
>>> This change adds in the watchdog timer support for the nct6686
>>> chip so that it can be used on the Lenovo m90n IOT device
>>>
[ ... ]
> 
> Would it be possible to get feedback on if anything else is needed for this patch please?
> We have customers wanting to use it, and we've ended up having to provide it as an out-of-tree module. Would love to get this integrated into the kernel properly.
> 

The locking in the driver is pretty much pointless since accesses
will be serialized by the watchdog core. At the same time, all
driver-local locking will not prevent access to the chip from the
nct6683 hwmon driver (which also supports nt6686). If both are
instantiated, I don't immediately see how they would not corrupt
each other.

Other than that, there is unexplained code such as nct6686_wdt_set_bank(),
which writes two bytes into the chip, and nct6686_wdt_reset_bank(),
which only writes one byte, but only conditionally if the bank is != 0.
That doesn't really "reset" the bank; at best it selects bank 0xff
unless bank 0 was requested. I don't really understand how that would be
"play safe" since it is not explained what that means. Besides, the hwmon
driver doesn't do that, so I don't understand the implications.

Actually, looking into both the this patch and the hwmon driver, it seems
that they are locking out each other, with "first driver to probe wins",
by reserving the access memory range for themselves. That is not acceptable.

I'll have to study the chip datasheets in detail to understand if
there are other potential issues, and I have not had the time to do that.

Guenter