linux-kernel - Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

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:	Sun, 04 Mar 2007 18:29:12 +0100
From:	Rudolf Marek <r.marek@...embler.cz>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Chuck Ebbert <cebbert@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	Pavel Machek <pavel@....cz>
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Hello again,

I produced some code which I proposed in mail above. The patch is not for review
it is just a PoC to better show what I'm trying to do. It is a test case for my
motherboard which has W83627EHF chip and ACPI thermal method and w83627ehf
compete the device.

When no driver is loaded, acpi is doing its own raw access to device. However
when the w83627ehf driver is loaded, the ACPI access to ports (0x295/0x296) is
forwarded to the w83627ehf driver.

How it works? I added one pointer to the struct resource which will contain a
pointer to the structure with callback functions. I know this is not an ideal
solution, but for a test it works fine. Everytime ACPI wants do IO it will ask
via ____request_resource(conflict, &res) if some driver claimed the resource,
if so, it iterates the resource structure to the last entry, if the callback
structure exists it is called (and device driver context is passed too), if not,
raw hw access is performed.

The routines in EHF driver partly emulates the chip, the address of which next
acpi access will want to read or write is saved in the data->reg_pointer.

The actual access to the chip is done only when the data port of the chip is
accessed, and driver generic io function is called. Bank register writes are
faked to the data->reg_bank. All access to the chip which is done in these
routines respects the "virtual" bank register which was previously set by ACPI.
(current emulation is not 100% perfect, but this could be easily fixed)
If something was written to the chip, driver's register cache is invalidated.

This approach does not need any external locking because the actual device
access is done by one function of driver (which already locks).

As from ACPI point of view the device behaves same way as real HW, the big plus
is that the driver actually KNOWs what is ACPI trying to do to the chip. Of
course if the HW access is done in SMM some other countermeasures must be
invented like GBL lock or the "take ownership" stuff.

Maybe this forwarder may be used by other drivers, which may want to know what
is ACPI doing to hardware during suspend/resume methods...

As I wrote earlier the SMBus access could be also virtualized same way, there
will be only more virtual registers, real transaction will start when the ACPI
sets the "begin transaction" bits ;).

Maybe the pointer to driver context could be removed, and container_of could be
used instead to reach it. I will need some advise how to implement this
randevouz between ACPI and one Linux driver... Exploiting the resource structure
  is nice but pehaps not acceptable??? Some class maybe? We have only 1:1
relation...

Thanks,
Rudolf

View attachment "acpi-io-sync.patch" of type "text/x-diff" (7825 bytes)