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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ