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: 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ