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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
