From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D656ECAAA7 for ; Mon, 29 Aug 2022 18:36:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229895AbiH2SgT (ORCPT ); Mon, 29 Aug 2022 14:36:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229831AbiH2SgP (ORCPT ); Mon, 29 Aug 2022 14:36:15 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A9617A772 for ; Mon, 29 Aug 2022 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661798174; x=1693334174; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=k2BmfC0sAJmubL13Fvo3U2D/VByPkcsTxGwgRVu4+mo=; b=kbQoO9WsL4BCpBjZYmYkwYVERgHNIaN9qfkeVhVEl2UM0sKii7r2eJJm qyddQ8omlm5Dq98qRAbxDuY4CvHotHEsVUxiaSRcFl2b5fuilfrXKfDRK AJjuy0YjlCow3z8HEdzkL+eKOxA+lVVizRVDCIq/BTCV82Gj3nA+dgk32 kA/jPFVPeWwZBtT+vR+cXnMuDD1rcCgr2fIRzaAxJS7BxQdZ87wRL8G0B YTfx4OQCQZOaiHHavkT5DKtFbWtJWo6yIpq+UTSzSSqUcCecLdHaiwQFq wUT4dL/ZBAOCzp78LEMu4JsIX6wuxRN3uuwWBFChQMN9ha/APL9+gnM3I Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10454"; a="293711355" X-IronPort-AV: E=Sophos;i="5.93,273,1654585200"; d="scan'208";a="293711355" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2022 11:36:13 -0700 X-IronPort-AV: E=Sophos;i="5.93,273,1654585200"; d="scan'208";a="611399748" Received: from rlacadex-mobl.amr.corp.intel.com (HELO [10.209.116.122]) ([10.209.116.122]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2022 11:36:13 -0700 Message-ID: Date: Mon, 29 Aug 2022 11:36:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] x86/microcode/intel: Allow late loading only if a min rev is specified Content-Language: en-US To: Ashok Raj , Borislav Petkov , Thomas Gleixner Cc: LKML Mailing List , X86-kernel , Andy Lutomirski , Ingo Molnar , Tom Lendacky , Tony Luck References: <20220829180436.716672-1-ashok.raj@intel.com> From: Dave Hansen In-Reply-To: <20220829180436.716672-1-ashok.raj@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/29/22 11:04, Ashok Raj wrote: > Any microcode that modifies the interface to an OS-visible feature > will set the min_version to itself. This will enforce this microcode is > not suitable for late loading unless the currently loaded revision is greater > or equal to the new microcode affecting the change. I know this hasn't quite made it into the normal Intel documentation channels. But, it would be nice to make sure that we have a _really_ solid description here of the architecture of min_rev which is *very* close to what the Intel folks building microcode images agreed to. This whole thing is useless if the architecture contract isn't ironclad and agreed to by both sides. One other thing on that note... The CPU itself authenticates the microcode. The OS trusts that the CPU will verify the integrity of the image. But, this min_rev is not part of the image that the CPU verifies, right? If you get your microcode images out of the back of a van in the shady part of town, nobody can promise that min_rev in the header follows the rules. I don't think we need to defend against that. I'm not sure we really even *can* defend against it. It's probably good to note, though.