linux-kernel - Re: Oops with tip/x86/fpu

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

Date:	Thu, 05 Mar 2015 10:41:08 -0800
From:	Dave Hansen <dave.hansen@...el.com>
To:	Oleg Nesterov <oleg@...hat.com>, Borislav Petkov <bp@...e.de>
CC:	Quentin Casasnovas <quentin.casasnovas@...cle.com>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Riikonen <priikone@....fi>,
	Rik van Riel <riel@...hat.com>,
	Suresh Siddha <sbsiddha@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Yu, Fenghua" <fenghua.yu@...el.com>
Subject: Re: Oops with tip/x86/fpu

On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
> On 03/05, Oleg Nesterov wrote:
>>
>> I _think_ that the difference is that eager_fpu_init()->xrstor_state()
>> was called before apply_alternatives(), so it used XRSTOR.
>>
>> Note also that (before this commit) restore_fpu_checking() was almost
>> never called right after init_fpu(). If use_eager_fpu() == T.
>>
>> After this commit the first xrstor_state() uses XRSTORS. And that is
>> how (I think) 'noxsaves' makes the difference.
>>
>>
>> So. I can be easily wrong, but so far I _think_ that this commit disclosed
>> another problem. And even if I am wrong and this commit is buggy, we need
>> to understand why ;)
>>
>> I'll try to think about debugging patch, I can't reproduce this problem
>> on my machine...
> 
> Dave. could please run the test-case below?
> 
> Without 'noxsaves', and without my commit.
> 
> Please compile it "cc --static -m32 -Wall T.c". In case you do not have
> the 32-bit libs, I also attached the static binary.
> 
> It should trigger another known problem which I was going to fix later,
> math_state_restore() wrongly does cli/sti. Please ignore the "sleeping
> function called from invalid context" warning in dmesg.
> 
> Does it trigger something else on your machine?

Triggers this:

> [  125.384358] general protection fault: 0000 [#1] SMP 
> [  125.390033] Modules linked in:
> [  125.393521] CPU: 0 PID: 1417 Comm: oleg-test Not tainted 3.19.0-00428-g4b2e762 #774
> [  125.402222] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2P1.86C.X062.R00.1411270820 11/27/2014
> [  125.416537] task: ffff88009af0e100 ti: ffff88009bf24000 task.ti: ffff88009bf24000
> [  125.425034] RIP: 0010:[<ffffffff810556cb>]  [<ffffffff810556cb>] math_state_restore+0x8b/0x1c0
> [  125.434839] RSP: 0000:ffff88009bf27e08  EFLAGS: 00010046
> [  125.440873] RAX: 00000000ffffffff RBX: ffff88009af0e100 RCX: 0000000000000000
> [  125.448972] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffff880148020780
> [  125.457073] RBP: ffff88009bf27e18 R08: 0000000000000000 R09: ffff880148020780
> [  125.465175] R10: 0000000000000001 R11: ffffffff817a0829 R12: ffff88009af0e100
> [  125.473274] R13: 0000000000000071 R14: 0000000000000200 R15: 0000000000000000
> [  125.481367] FS:  0000000000000000(0003) GS:ffff88014e400000(0063) knlGS:00000000089ea840
> [  125.490551] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
> [  125.497075] CR2: 0000000000000071 CR3: 000000007f8ce000 CR4: 00000000003407f0
> [  125.505177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  125.513283] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [  125.521381] Stack:
> [  125.523664]  0000000000000000 00000000ffffffff ffff88009bf27ed8 ffffffff81061106
> [  125.532114]  ffff880148020780 000000019be24928 0000000000000000 0000000000000000
> [  125.540571]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [  125.549032] Call Trace:
> [  125.551814]  [<ffffffff81061106>] __restore_xstate_sig+0x246/0x6c0
> [  125.558841]  [<ffffffff810ace1f>] ? recalc_sigpending+0x1f/0x60
> [  125.565555]  [<ffffffff8109d054>] ia32_restore_sigcontext+0x194/0x1b0
> [  125.572874]  [<ffffffff8109d4bd>] sys32_rt_sigreturn+0xad/0xd0
> [  125.579505]  [<ffffffff817a0985>] ia32_ptregs_common+0x25/0x4b
> [  125.586129] Code: fb 7e e9 11 00 00 00 db e2 0f 77 db 83 44 06 00 00 0f 1f 80 00 00 00 00 0f 1f 44 00 00 b8 ff ff ff ff 48 8b bb 48 06 00 00 89 c2 <48> 0f c7 1f 31 c0 eb 20 0f 1f 44 00 00 bf 9a 00 00 00 e8 ce 11 
> [  125.608467] RIP  [<ffffffff810556cb>] math_state_restore+0x8b/0x1c0
> [  125.615599]  RSP <ffff88009bf27e08>
> [  125.619563] ---[ end trace 71f0a6784c4b2590 ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/