From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933332AbbGJPML (ORCPT ); Fri, 10 Jul 2015 11:12:11 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:48298 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932981AbbGJPME (ORCPT ); Fri, 10 Jul 2015 11:12:04 -0400 X-Sasl-enc: 9Et0GuPEWX61ONa6tPggmvZUNr+cWqMvEtdCi0WIEIIU 1436541123 Date: Fri, 10 Jul 2015 12:12:00 -0300 From: Henrique de Moraes Holschuh To: Borislav Petkov Cc: LKML , Aravind Gopalakrishnan , X86 ML Subject: Re: [PATCH 0/2] x86/microcode/amd: Do not overwrite specific patch levels Message-ID: <20150710151159.GA761@khazad-dum.debian.net> References: <1435781656-1890-1-git-send-email-bp@alien8.de> <20150709150341.GB23766@khazad-dum.debian.net> <20150710101151.GA7538@nazgul.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710101151.GA7538@nazgul.tnic> 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 On Fri, 10 Jul 2015, Borislav Petkov wrote: > On Thu, Jul 09, 2015 at 12:03:41PM -0300, Henrique de Moraes Holschuh wrote: > > Is there any way to notify the user that 'processor microcode updates > > are not available on this system except through a firmware update' ? > > What for? > > Those microcode patch levels are final and shouldn't be upgraded at all. Yes, I understand that the operating system is not to attempt to update any microcode that is listed as 'final'. However, if that requirement exists because a microcode update applied by the operating system would interact badly with the current firmware (or microcode), the user could still get newer microcode (and better features, errata workarounds, etc) through a full firmware (BIOS/EFI) update. OTOH, if this is a 'microcode updates newer than the 'final' version exist only to support changed hardware designs', and thus a board that already works with 'final' should never need newer microcode, it would be nice to know that fact. Anyway, the code does not look like what I would expect if it is the later case ("updates past 'final' exist only to support for changed hardware design): it blacklists updates from 'final' to anything else, but it still allows microcode with a version that is less than 'final' to be updated to something that is higher than 'final', etc. -- "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