Date: Tue, 30 Jun 2015 07:16:54 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>, Ingo Molnar <mingo@elte.hu>,
        LKML <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Denys Vlasenko <dvlasenk@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
        Dave Hansen <dave@sr71.net>
Subject: Re: [all better] Re: regression: massive trouble with fpu rework
Message-ID: <20150630051654.GB5782@gmail.com>
References: <1435386316.3664.23.camel@gmail.com>
 <1435393129.3490.7.camel@gmail.com>
 <20150627082514.GA10894@gmail.com>
 <1435395328.6545.10.camel@gmail.com>
 <20150629064008.GA16251@gmail.com>
 <1435566329.2900.1.camel@gmail.com>
 <20150629083302.GA13113@pd.tnic>
 <1435580843.2866.5.camel@gmail.com>
 <20150629130921.GF12383@pd.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150629130921.GF12383@pd.tnic>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1338
Lines: 35


* Borislav Petkov <bp@alien8.de> wrote:

> On Mon, Jun 29, 2015 at 02:27:23PM +0200, Mike Galbraith wrote:
> > With it commented out, and fpu__init_system() either back at previously
> > booting position [5] or at original [0], doesn't matter, box is dead,
> > but differently.  It stalls after setting clocksource to tsc, and just
> > sits there.
> 
> ... which means that unmasking the CPUID features is absolutely needed
> on Linux. Not unmasking probably triggers this original bug which
> 
>   066941bd4eeb ("x86: unmask CPUID levels on Intel CPUs")
> 
> fixed.

Yes.

And I'd consider us hanging a separate (but not high prio) bug: the kernel should 
be robust as long as the CPUID data is stable. In that sense the original fix is 
right (we really want to unmask all available CPUID leaves), but it also masked 
another (less severe) kernel bug.

For example virtualization is known to tweak CPUID details creatively, and 
firmware (as this example shows it) can mess it up a well, so we generally want to 
treat it as untrusted input data that needs to be validated.

Thanks,

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