From nobody Mon Feb 9 17:59:24 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1603733170; cv=none; d=zohomail.com; s=zohoarc; b=XuC5gTrMIcww1g6S8pZFItUUJooXoKi/aS82Dr1qeULMS2B/dnSsVRqOCdnuG0YQ/31IxOe5qmQlGwAiyXxlwtUEWmgNkdZ+PZl7BDbR+Gq12xU7K0eGtJHc5FNqTcEJkg23gDLHfNpWw8mCL3tLRF+qG/LlAzpepzHHVvRO7zM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1603733170; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=lMGDo2tWGmCcW66JTmswfaXrfGYgSEz1+dtFVx6vTGc=; b=atFWvpYdAe26WiCwwNDNcAEGLofGP9ft43BK+r0Nlb/OT5eceqpqvzSxINXkluK4jEmvBg45GmB67Ekpl+hOTGl1PJ0boZTX7+HQZiDLhTDI15cJLFhlZ1lWUHIQZ90Kt7TCSppu/7FFjk1LoUo0rsN+3M7HQBB/kvRtbtT58PM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1603733170887353.30430922654637; Mon, 26 Oct 2020 10:26:10 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.12500.32558 (Exim 4.92) (envelope-from ) id 1kX6Fn-0004Qt-1d; Mon, 26 Oct 2020 17:25:55 +0000 Received: by outflank-mailman (output) from mailman id 12500.32558; Mon, 26 Oct 2020 17:25:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX6Fm-0004Ql-TS; Mon, 26 Oct 2020 17:25:54 +0000 Received: by outflank-mailman (input) for mailman id 12500; Mon, 26 Oct 2020 17:25:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX6Fm-0004NA-8Z for xen-devel@lists.xenproject.org; Mon, 26 Oct 2020 17:25:54 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 392e3e4d-20cc-4b4b-9c39-092efdd340f3; Mon, 26 Oct 2020 17:25:48 +0000 (UTC) Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kX6Fm-0004NA-8Z for xen-devel@lists.xenproject.org; Mon, 26 Oct 2020 17:25:54 +0000 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 392e3e4d-20cc-4b4b-9c39-092efdd340f3; Mon, 26 Oct 2020 17:25:48 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 392e3e4d-20cc-4b4b-9c39-092efdd340f3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1603733148; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=N4NLiVkpafLkQts7MJNqLznQ4pqesNjOindufP348ms=; b=RnPdwy9AUT3oMlWbDGsL5uhgMgtRPT6DpYUGHaropY2CMf45K0Nw+hNE NTZYgQO2ErwzMvRtkzVW+8Q+jZ3cl0yr4u3NjzgwsiX9k3mo9BqNVtwOa lIRR9szV+INyR3QZxLT4XdelX+yFPyjFFMAPiItd3bfl0IEDVB9a856sq Y=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: J99NVkgohU6w6HUzF9IbgBNlOWf42KScqzdOM8z/aI5qBup5FpJUuPGBNhU1t3/xRr6hft6CKk b19A6S88I6fttt4FHelpS8ers3deLh7BYL144+Up3wDy410uT1yP1NyX8JbkaIJxOm2HVTdyw2 /Kxtp5OjDt1qM3OccRqE2xWszu6ObMx9neDN141JPTbN7YiENKXCHUQD5ghg+wjK19eX0W3+hP DOfUvbLVEzwqDwzcjWj4Ec/GlsB4m9zOs8LbN+JlFo7yuhXbnYlP7Xdf5h7xsYsmMkj+rn1YDd rjc= X-SBRS: None X-MesageID: 30048907 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.77,420,1596513600"; d="scan'208";a="30048907" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Juergen Gross , Igor Druzhinin Subject: [PATCH 2/3] x86/ucode/intel: Fix handling of microcode revision Date: Mon, 26 Oct 2020 17:25:18 +0000 Message-ID: <20201026172519.17881-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20201026172519.17881-1-andrew.cooper3@citrix.com> References: <20201026172519.17881-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) For Intel microcodes, the revision field is signed (as documented in the SD= M) and negative revisions are used for pre-production/test microcode (not documented publicly anywhere I can spot). Adjust the revision checking to match the algorithm presented here: https://software.intel.com/security-software-guidance/best-practices/micr= ocode-update-guidance This treats pre-production microcode as always applicable, but also product= ion microcode having higher precident than pre-production. It is expected that anyone using pre-production microcode knows what they are doing. This is necessary to load production microcode on an SDP with pre-production microcode embedded in firmware. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu CC: Juergen Gross CC: Igor Druzhinin "signed" is somewhat of a problem. The actual numbers only make sense as sign-magnitude, and not as twos-compliement, which is why the rule is "any debug microcode goes". The actual upgrade/downgrade rules are quite complicated, but in general, a= ny change is permitted so long as the Security Version Number (embedded inside the patch) doesn't go backwards. --- xen/arch/x86/cpu/microcode/intel.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcod= e/intel.c index e1ccb5d232..5fa2821cdb 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -33,7 +33,7 @@ =20 struct microcode_patch { uint32_t hdrver; - uint32_t rev; + int32_t rev; uint16_t year; uint8_t day; uint8_t month; @@ -222,12 +222,23 @@ static int microcode_sanity_check(const struct microc= ode_patch *patch) return 0; } =20 +/* + * Production microcode has a positive revision. Pre-production microcode= has + * a negative revision. + */ static enum microcode_match_result compare_revisions( - uint32_t old_rev, uint32_t new_rev) + int32_t old_rev, int32_t new_rev) { if ( new_rev > old_rev ) return NEW_UCODE; =20 + /* + * Treat pre-production as always applicable - anyone using pre-produc= tion + * microcode knows what they are doing, and can keep any resulting pie= ces. + */ + if ( new_rev < 0 ) + return NEW_UCODE; + return OLD_UCODE; } =20 --=20 2.11.0