linux-kernel - Re: Thermal driver with safeguards

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] [day] [month] [year] [list]

Message-ID: <2de53940-d379-4b50-bacf-6849583acbc8@tuxedocomputers.com>
Date: Tue, 14 Jan 2025 11:14:44 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Pavel Machek <pavel@....cz>
Cc: "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>, rui.zhang@...el.com,
 Hans de Goede <hdegoede@...hat.com>, Armin Wolf <W_Armin@....de>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 platform-driver-x86@...r.kernel.org
Subject: Re: Thermal driver with safeguards

Hi,

Am 13.01.25 um 23:17 schrieb Pavel Machek:
> Hi!
>
>>> given a pair of a temperature sensor and a fan, I want to implement a
>>> driver. that allows userspace to directly control the fan if it wants
>>> to. But have a minimum fan speed when certain high temperatures are
>>> reached to avoid crashes or hardware damage.
>>>
>>> e.g.
>>>
>>> - temperature of target die is 80°C -> fan speed must be at least 30%
>>>
>>> - temperature of target die is 90°C -> fan speed must be at least 40%
>>>
>>> - temperature of target die is 105°C -> fan speed must be 100%
>>>
>>> - temperature of target die is 110°C -> device shuts off to protect the hardware
>>>
>>> Would the thermal subsystem be the right place for this to implement
>>> this protection in driver?
> Best place to implement this would be hardware... It should
> self-protect.
Don't know what you mean by this: The lowest level of logic that could handle 
something like this is the EC firmware.
>
> Next best place is embedded controller.

I agree, but I'm working on upstreaming a driver that is also for devices that 
are multiple years out of production. They will not get a firmware update.

Also for new devices the EC firmware is usually delivered as a binary blob by 
the mainboard ODMs.

So the lowest possible level of logic I as a developer can actually do something 
about this lack of protection is the kernel.

Please don't assume that we, as in TUXEDO Computers, do not try to talk to the 
ODMs about this and other problems we see with the EC firmware. We do. But 
matter of fact is, that all this does not help with devices out now. These need 
to be fixed in driver instead.

Best regards,

Werner Sembach

>
> Yes, kernel can probably do that, too, but then you risk running "hot"
> when kernel panics, when someone boots 2.16 kernel, or DOS or ...
>
> Best regards,
>
> 								Pavel