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 98BD9C54EAA for ; Mon, 30 Jan 2023 21:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231388AbjA3VkY (ORCPT ); Mon, 30 Jan 2023 16:40:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230480AbjA3VkQ (ORCPT ); Mon, 30 Jan 2023 16:40:16 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90F9546B0 for ; Mon, 30 Jan 2023 13:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675114815; x=1706650815; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=l2C4mQekfCyd1yvV8K4Udyf0Ac0fLPq/4sH1liSL9+g=; b=C0jv8lXIN8PPRqhuTota0XaWw/eSl2psMv/MvmhbvJmzcoNmgfKM21Ox 2hLmFfMlfUNViJjuQxhKWs7gd8bfK9aDqvaiSMmqcAR6Gde8ugX8kWwFx EhOnaQS/48WoKL7anf+bcvv3VY9jBT4buIwZYJ8D/qYau7x685ilO9PgW Pq7nAI9llc4ljYMsGGipbZMPGonUmjAY8iuFlb828uRwag5WZhKkhwvKa TfkJSliQUDLj2448hErV6hOGGwEJuQvVfpjnFzPU52bQ5s6WMp5OFGFuB bB/i6GqHV2/GYCJSFptpu1L4h95iCcjQl69x+gICkS54vGTmB+yv4Z02E g==; X-IronPort-AV: E=McAfee;i="6500,9779,10606"; a="328955516" X-IronPort-AV: E=Sophos;i="5.97,259,1669104000"; d="scan'208";a="328955516" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jan 2023 13:40:13 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10606"; a="696571867" X-IronPort-AV: E=Sophos;i="5.97,259,1669104000"; d="scan'208";a="696571867" Received: from araj-ucode.jf.intel.com ([10.23.0.19]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jan 2023 13:40:12 -0800 From: Ashok Raj To: Borislav Petkov , Thomas Gleixner Cc: Ashok Raj , LKML , x86 , Ingo Molnar , Tony Luck , Dave Hansen , Alison Schofield , Reinette Chatre , Tom Lendacky , Stefan Talpalaru , David Woodhouse , Benjamin Herrenschmidt , Jonathan Corbet , "Rafael J . Wysocki" , Peter Zilstra , Andy Lutomirski , Andrew Cooper , Boris Ostrovsky , Martin Pohlack Subject: [Patch v3 Part2 4/9] x86/microcode: Do not call apply_microcode() on sibling threads Date: Mon, 30 Jan 2023 13:39:50 -0800 Message-Id: <20230130213955.6046-5-ashok.raj@intel.com> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230130213955.6046-1-ashok.raj@intel.com> References: <20230130213955.6046-1-ashok.raj@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Microcode updates are applied at the core, so an update to one HT sibling is effective on all HT siblings of the same core. During late-load, after the primary has updated the microcode, it also reflects that in the per-cpu structure (cpuinfo_x86) holding the current revision. Current code calls apply_microcode() to update the SW per-cpu revision. But in the odd case when primary returned with an error, and as a result the secondary didn't get the revision updated, will attempt to perform a patch load and the primary has already been released to the system. This could be problematic, because the whole rendezvous dance is to prevent updates when one of the siblings could be executing arbitrary code. Replace apply_microcode() with a call to collect_cpu_info() and let that call also update the per-cpu structure instead of returning the previously cached values. Suggested-by: Thomas Gleixner Signed-off-by: Ashok Raj Cc: LKML Cc: x86 Cc: Ingo Molnar Cc: Tony Luck Cc: Dave Hansen Cc: Alison Schofield Cc: Reinette Chatre Cc: Thomas Gleixner (Intel) Cc: Tom Lendacky Cc: Stefan Talpalaru Cc: David Woodhouse Cc: Benjamin Herrenschmidt Cc: Jonathan Corbet Cc: Rafael J. Wysocki Cc: Peter Zilstra (Intel) Cc: Andy Lutomirski Cc: Andrew Cooper Cc: Boris Ostrovsky Cc: Martin Pohlack --- arch/x86/kernel/cpu/microcode/core.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index e4b4dfcf2d18..8452fad89bf6 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -386,6 +386,7 @@ static int __wait_for_cpus(atomic_t *t, long long timeout) static int __reload_late(void *info) { int cpu = smp_processor_id(); + struct ucode_cpu_info *uci; enum ucode_state err; int ret = 0; @@ -421,12 +422,13 @@ static int __reload_late(void *info) /* * At least one thread has completed update on each core. - * For others, simply call the update to make sure the - * per-cpu cpuinfo can be updated with right microcode - * revision. + * For siblings, collect the cpuinfo and update the + * per-cpu cpuinfo with the current microcode revision. */ - if (cpumask_first(topology_sibling_cpumask(cpu)) != cpu) - err = microcode_ops->apply_microcode(cpu); + if (cpumask_first(topology_sibling_cpumask(cpu)) != cpu) { + uci = ucode_cpu_info + cpu; + microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig); + } return ret; } -- 2.37.2