linux-kernel - Re: [PATCH] i8k: Add support for temperature sensor labels

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, 30 Nov 2014 11:11:35 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Steven Honeyman <stevenhoneyman@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i8k: Add support for temperature sensor labels

On Sunday 30 November 2014 02:25:09 Guenter Roeck wrote:
> On 11/29/2014 11:07 AM, Pali Rohár wrote:
> [ ... ]
> 
> > Original Dell DOS executable ignores all temperature sensors
> > if type SMM function fails (if I decoded and understand
> > that DOS assembler code correctly). So maybe we should do
> > same...
> 
> Pali,
> 
> Makes me wonder - does the assembler code tell you what to do
> if the reported temperature is invalid, and does it
> distinguish between error codes ?

I do not see anything like that. But there are lot of indirect 
calls (offset to pointer to function is stored in some global at 
init zero data), so it is hard to understand what that DOS binary 
is doing. I'm happy that I decoded loop which trying to call that 
type function and if it does not fail then it call read 
temperature function. And in that section I do not see any error 
handling of invalid values (but it could be somewhere else).

Anyway DOS binary is quite old (7 years maybe?). It is not even 
available for my last E6440 model. Now all new Dell laptops have 
EFI system and ePSA application (new version of diagnostic tool 
which reports info about fan, temperature, ...). That tool looks 
like is burned directly into machine (I can start it with empty 
HDD from Setup screen) or into BIOS image.

And what is interesting about this ePSA:

* it show more temperature sensors (battery temperature)
* it show correct RPM of fan and *can* control fan speed

I think that DOS binary has no idea about Optimus or PowerExpress 
cards so for that error handling we need to understand what is 
doing new EFI ePSA application...

And because function for turning card on/off is controlled via 
ACPI I bet that DOS or EFI application does not touch it, so 
assume that card is always on and does not need any error 
handling.

Another info about DOS binary: After SMM code for reading fan RPM 
is finished, then function divide returned RPM value by some 
number stored in local data. So now I think that magic fan 
multiplier is not constant, but runtime value. I will try to look 
at it, if we can fix this problem in linux i8k.c.

> So far we have
> 	0x99 - presumably a spurious error
> 	0xc1 - GPU temperature sensor, GPU turned off
> 
> It would be nice if we could find a better solution for error
> handling.
> 

Yes, but now we can only guess... My idea is that Dell SMM 
handler does not check GPU presence at runtime and just try to 
read info from PCI bus. And because turned off card is not there 
just random (or non random) garbage is returned...

> Thanks,
> Guenter

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)