Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753726AbbGINNq (ORCPT ); Thu, 9 Jul 2015 09:13:46 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:58577 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803AbbGINNp (ORCPT ); Thu, 9 Jul 2015 09:13:45 -0400 X-Sasl-enc: ZhZ5lDvlQrvsHf7/wskiYL78ilXkCdIUb9S16sruqmNN 1436447624 Date: Thu, 9 Jul 2015 10:13:40 -0300 From: Henrique de Moraes Holschuh To: Ingo Molnar Cc: Borislav Petkov , Mike Galbraith , Ingo Molnar , LKML , "H. Peter Anvin" , Thomas Gleixner , Andy Lutomirski , Denys Vlasenko , Oleg Nesterov , Dave Hansen Subject: Re: [all better] Re: regression: massive trouble with fpu rework Message-ID: <20150709131340.GA23766@khazad-dum.debian.net> 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> <20150630051654.GB5782@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150630051654.GB5782@gmail.com> X-GPG-Fingerprint1: 4096R/39CB4807 C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 X-GPG-Fingerprint2: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1347 Lines: 28 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/