[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150709131340.GA23766@khazad-dum.debian.net>
Date: Thu, 9 Jul 2015 10:13:40 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Ingo Molnar <mingo@...nel.org>
Cc: Borislav Petkov <bp@...en8.de>,
Mike Galbraith <umgwanakikbuti@...il.com>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
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
On Tue, 30 Jun 2015, Ingo Molnar wrote:
> 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.
Processor microcode updates can also change cpuid information, at least on
Intel. There are Intel microcode updates in the field that do this.
Specific Intel MSR writes *should* be able to change cpuid information as
well, as they enable/disable features that are reflected by a cpuid bit.
I have no idea about AMD, though.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
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