linux-kernel - Re: [PATCH] x86/fpu: always restore_xinit_state() when !use_eager

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]

Message-ID: <553E4BB2.2040603@intel.com>
Date:	Mon, 27 Apr 2015 07:46:10 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Bobby Powers <bobbypowers@...il.com>, linux-kernel@...r.kernel.org
CC:	x86@...nel.org, Oleg Nesterov <oleg@...hat.com>,
	Borislav Petkov <bp@...e.de>, Ingo Molnar <mingo@...nel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Riikonen <priikone@....fi>,
	Quentin Casasnovas <quentin.casasnovas@...cle.com>,
	Rik van Riel <riel@...hat.com>,
	Suresh Siddha <sbsiddha@...il.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86/fpu: always restore_xinit_state() when !use_eager_cpu()

On 04/26/2015 03:04 PM, Bobby Powers wrote:
> Oleg's commit f893959b ("x86/fpu: Don't abuse drop_init_fpu() in
> flush_thread()") removed drop_init_fpu() usage from flush_thread.
> This seems to break things for me - the Go 1.4 test suite fails all
> over the place with floating point comparision errors (offending
> commit found through bisection).

First of all, I really appreciate the bug report and the bisection.  Thanks!

Which hardware was this seen on?  Do you have any idea which part of the
test suite failed, or what actually _caused_ it to fail?

> The functional change was that flush_thread after f893959b only calls
> restore_init_xstate when both !use_eager_fpu and !used_math are true.
> drop_init_fpu (now fpu_reset_state) calls restore_init_xstate()
> regardless of whether current used_math().

This is really interesting.  We were seeing some issues where the xstate
was not getting cleared across an exec, which seemed silly, but we just
assumed it was something that had always been there.

BTW, I think restore_init_xstate() is probably buggy for the !fxsave and
softfpu cases.

> static inline void restore_init_xstate(void)
> {
>         if (use_xsave())
>                 xrstor_state(init_xstate_buf, -1);
>         else
>                 fxrstor_checking(&init_xstate_buf->i387);
> }

I'll do some testing of this today and make sure it doesn't break the
things that I saw Oleg's patch "fix".

--
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/