linux-kernel - Re: [PATCH 7/7] hwmon: iio: Add alarm support

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: <759e8070-de3e-41fd-8e81-05e22c32209e@roeck-us.net>
Date: Tue, 15 Jul 2025 12:34:48 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Sean Anderson <sean.anderson@...ux.dev>,
 Jonathan Cameron <jic23@...nel.org>, Jean Delvare <jdelvare@...e.com>,
 linux-iio@...r.kernel.org, linux-hwmon@...r.kernel.org
Cc: Andy Shevchenko <andy@...nel.org>, Nuno Sá
 <nuno.sa@...log.com>, linux-kernel@...r.kernel.org,
 David Lechner <dlechner@...libre.com>
Subject: Re: [PATCH 7/7] hwmon: iio: Add alarm support

On 7/14/25 18:20, Sean Anderson wrote:
> Add alarm support based on IIO threshold events. The alarm is cleared on
> read, but will be set again if the condition is still present. This is
> detected by disabling and re-enabling the event. The same trick is done
> when creating the attribute to detect already-triggered events.
> 
> The alarms are updated by an event listener. To keep the notifier call
> chain short, we create one listener per iio device, shared across all
> hwmon devices.
> 
> To avoid dynamic creation of alarms, alarms for all possible events are
> allocated at creation. Lookup is done by a linear scan, as I expect
> events to occur rarely. If performance becomes an issue, a binary search
> could be done instead (or some kind of hash lookup).
> 

I am very concerned about this. The context suggests that the iio events
are just that - events without specific association to hardware or system
limits. Hardware monitoring limits are system specific limits, which are not
supposed to change at runtime. A high voltage or temperature warning is
just that - it is not supposed to trigger a change in the event limit.
If anything, it is supposed to trigger some action to bring the observed
value back to normal.

For this series to move forward, there needs to be some guarantee that
the limits are used and usable only as intended, and can not be used for
random thresholds. The idea of "if a temperature alarm is triggered, do
something and change the threshold temperature" is not an acceptable use
for hardware monitoring alarms.

Guenter