Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1174748

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

From "H. Peter Anvin" <hpa@zytor.com>
Newsgroups linux.kernel
Subject Re: [all better] Re: regression: massive trouble with fpu rework
Date 2015-06-30 22:30 +0200
Message-ID <pHakj-4aX-39@gated-at.bofh.it> (permalink)
References (5 earlier) <pGCBY-5Y6-7@gated-at.bofh.it> <pGCLD-69E-7@gated-at.bofh.it> <pGGme-2Tk-13@gated-at.bofh.it> <pGGYX-3RN-35@gated-at.bofh.it> <pGW7E-uZ-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 06/29/2015 10:16 PM, Ingo Molnar wrote:
> 
> * 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.
> 

Well, that is not *entirely* possible, since if the data is just plain
wrong, we're screwed no matter what.

However, we could deal with CPUID level capping.  The best way to do
that is probably to have a table of CPU features and the minimum
required CPUID level for each.  If maximum CPUID level < that level,
disable that feature.

	-hpa


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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[all better] Re: regression: massive trouble with fpu rework Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-06-27 10:20 +0200
  Re: [all better] Re: regression: massive trouble with fpu rework Ingo Molnar <mingo@kernel.org> - 2015-06-27 10:30 +0200
    Re: [all better] Re: regression: massive trouble with fpu rework Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-06-27 11:00 +0200
      Re: [all better] Re: regression: massive trouble with fpu rework Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2015-06-27 23:10 +0200
        Re: [all better] Re: regression: massive trouble with fpu rework Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2015-06-29 03:20 +0200
      Re: [all better] Re: regression: massive trouble with fpu rework "H. Peter Anvin" <hpa@zytor.com> - 2015-06-30 22:30 +0200

csiph-web