linux-kernel - Re: [all better] Re: regression: massive trouble with fpu rework

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: <20150630051416.GA5782@gmail.com>
Date:	Tue, 30 Jun 2015 07:14:16 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Dave Hansen <dave@...1.net>
Subject: Re: [all better] Re: regression: massive trouble with fpu rework


* H. Peter Anvin <hpa@...or.com> wrote:

> On 06/29/2015 02:35 AM, Ingo Molnar wrote:
> > 
> > Indeed, I bet that makes a difference!
> > 
> > I wish that 'unmasking' logic came with more comments:
> > 
> >   - Why do BIOSen ever mask CPUIDs?
> > 
> 
> To work around bugs in legacy operating systems.
>
> >   - Why do we unmask the masking?
> 
> Because we don't have those specific bugs.

Great - would be nice to put those reasons between /* */ markers, to keep future 
generations (and overworked maintainers!) from wondering.

> >   - Why doesn't the kernel keep on working just fine even if certain CPUID aspects 
> >     are turned off?
> 
> Because it exercises code paths that are otherwise impossible, for example, it 
> exposes the XSAVE capability without exposing the XSAVE information in higher 
> CPUID leaves.
> 
> The other option would be to have a list of CPU features that should be turned 
> off whenever the CPUID leaf maximum is too low, but it gives a better user 
> experience to just override the BIOS capping and then we have fewer code paths 
> in the kernel to worry about.

1)

As a side note, I think we should generally be robust enough to recognize pretty 
much any CPUID 'mischief' and at minimum not crash.

2)

But this FPU crash is different, here the reason for the crash is the following 
bug in the FPU code:

	fpu__init_system(); /* inits the FPU based on masked CPUID */

	... CPUID *extends* ...

	fpu__init_cpu(); /* Actually uses the FPU now based on the expanded CPUID */

        *KABOOM*

I.e. we (obviously) should not base half on the FPU logic on different CPUID bits 
than the other half of the FPU logic.

I'll queue up the fix, which is to do the early FPU init after our CPUID state 
stabilizes. (i.e. the second patch I sent to Mike.)

Thanks,

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