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  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:   Fri, 24 Nov 2017 12:13:40 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     Oleksandr Natalenko <oleksandr@...alenko.name>
Cc:     Jonathan Buzzard <jonathan@...zard.org.uk>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mario Limonciello <mario.limonciello@...l.com>
Subject: Re: i8k_smm_func() takes enormous of time to execute

On Thursday 23 November 2017 22:41:03 Oleksandr Natalenko wrote:
> Hi, Jonathan, Mario et al.
> 
> I've noticed that querying Dell Vostro 3360 hwmon sensor freezes the system 
> completely (like, really completely, even mouse cursor does not move, and 
> sound playback stops) for approx. half of a second. Then, system recovers and 
> runs as usual. Also, sensor readings are okay, for instance:
> 
> ===
> $ sensors dell_smm-virtual-0
> dell_smm-virtual-0
> Adapter: Virtual device
> Processor Fan: 5615 RPM
> CPU:            +51.0°C  
> Ambient:        +36.0°C  
> Other:          +63.0°C  
> SODIMM:         +41.0°C 
> ===
> 
> So, I've used trace-cmd to check what takes that much amount of time to 
> execute, and got this:
> 
> ===
> # trace-cmd record -p function_graph -l i8k_smm -F sensors dell_smm-virtual-0
> $ trace-cmd report
> ...
> sensors-23694 [002] 89099.214369: funcgraph_entry:      # 503440.746 us |  
> i8k_smm();
> ...
> ===
> 
> Clearly, 0.5 s delay.
> 
> Looking at i8k_smm(), it calls i8k_smm_func() on 0th CPU:
> 
> ===
>  232     ret = smp_call_on_cpu(0, i8k_smm_func, regs, true);
> ===
> 
> which, in turn, does some asm magic.

Hi! If you compile module with DEBUG, then i8k_smm_func function print
into dmes how much time it spend in SMM mode. And also it print which
SMM action it was.

Therefore you would be able to figure out which SMM call (which is just
RPC) cause this freeze.

Basically when CPU is in SMM mode, then execution of kernel is stopped
and kernel does not know that such thing happened. So it is up to the
SMM implementation to return control ASAP back to non-SMM mode.

Kernel has no control over SMM, it can be fixed only by vendor by new
BIOS or firmware update.

What we can do is just identify problematic calls and avoid their usage.

This problem is independent of kernel or whole operating system.

> I know that SMM is kinda "black box", and kernel has little to do with it, but 
> I think that under Windows, for instance, it would work without freezes. So, 
> likely, querying SMM might be done differently.
> 
> I do not know how to approach this issue, thus asking for help/advice. Also, 
> CCing Jonathan since the comment before asm magic says this:
> 
> ===
>  137  * Call the System Management Mode BIOS. Code provided by Jonathan 
> Buzzard.
> ===
> 
> This was also reported in various places before, for instance, [1], but 
> unfortunately, without any solution.
> 
> Thanks.
> 
> Regards,
>   Oleksandr
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/10490

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

Powered by blists - more mailing lists