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 CED3DC6FA99 for ; Fri, 10 Mar 2023 14:54:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbjCJOyJ (ORCPT ); Fri, 10 Mar 2023 09:54:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233522AbjCJOxj (ORCPT ); Fri, 10 Mar 2023 09:53:39 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94963123DEC for ; Fri, 10 Mar 2023 06:49:35 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 333716196E for ; Fri, 10 Mar 2023 14:48:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 305B8C433EF; Fri, 10 Mar 2023 14:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1678459738; bh=3axzQABghvmE2Q0uMqGPD8yZEbETNwKXLkjkyXorML4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P8aBzv+NfWQAOcoho0fzwVt8OC7e1JL6JNy2xoC0HqTkV1MEArhHRMEwLhlA7Ut5q xU4ohKngDT0vyUDZsyrWW6pA9swvBWmZi8DdrCaV6j0wRlG6CmLZcdvCDBetKhQ1Vp Tq2F3OntA5rCJB7JwetYztldUqZjs5QcPZH3skio= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Peter Zijlstra (Intel)" , Borislav Petkov , Thomas Gleixner , Sasha Levin Subject: [PATCH 5.10 103/529] x86/microcode: Default-disable late loading Date: Fri, 10 Mar 2023 14:34:06 +0100 Message-Id: <20230310133809.747158423@linuxfoundation.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230310133804.978589368@linuxfoundation.org> References: <20230310133804.978589368@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Borislav Petkov [ Upstream commit a77a94f86273ce42a39cb479217dd8d68acfe0ff ] It is dangerous and it should not be used anyway - there's a nice early loading already. Requested-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220525161232.14924-3-bp@alien8.de Stable-dep-of: c0dd9245aa9e ("x86/microcode: Check CPU capabilities after late microcode update correctly") Signed-off-by: Sasha Levin --- arch/x86/Kconfig | 11 +++++++++++ arch/x86/kernel/cpu/common.c | 2 ++ arch/x86/kernel/cpu/microcode/core.c | 7 ++++++- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1f55fc6470371..2284666e8c90c 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1329,6 +1329,17 @@ config MICROCODE_AMD If you select this option, microcode patch loading support for AMD processors will be enabled. +config MICROCODE_LATE_LOADING + bool "Late microcode loading (DANGEROUS)" + default n + depends on MICROCODE + help + Loading microcode late, when the system is up and executing instructions + is a tricky business and should be avoided if possible. Just the sequence + of synchronizing all cores and SMT threads is one fragile dance which does + not guarantee that cores might not softlock after the loading. Therefore, + use this at your own risk. Late loading taints the kernel too. + config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" help diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 4402589a1ee19..95f52540db378 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2129,6 +2129,7 @@ void cpu_init_secondary(void) } #endif +#ifdef CONFIG_MICROCODE_LATE_LOADING /* * The microcode loader calls this upon late microcode load to recheck features, * only when microcode has been updated. Caller holds microcode_mutex and CPU @@ -2158,6 +2159,7 @@ void microcode_check(void) pr_warn("x86/CPU: CPU features have changed after loading microcode, but might not take effect.\n"); pr_warn("x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.\n"); } +#endif /* * Invoked from core CPU hotplug code after hotplug operations diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index 8d8d7ee47e1ce..5b27030714e43 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -393,6 +393,7 @@ static int apply_microcode_on_target(int cpu) /* fake device for request_firmware */ static struct platform_device *microcode_pdev; +#ifdef CONFIG_MICROCODE_LATE_LOADING /* * Late loading dance. Why the heavy-handed stomp_machine effort? * @@ -560,6 +561,9 @@ static ssize_t reload_store(struct device *dev, return ret; } +static DEVICE_ATTR_WO(reload); +#endif + static ssize_t version_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -576,7 +580,6 @@ static ssize_t pf_show(struct device *dev, return sprintf(buf, "0x%x\n", uci->cpu_sig.pf); } -static DEVICE_ATTR_WO(reload); static DEVICE_ATTR(version, 0444, version_show, NULL); static DEVICE_ATTR(processor_flags, 0444, pf_show, NULL); @@ -729,7 +732,9 @@ static int mc_cpu_down_prep(unsigned int cpu) } static struct attribute *cpu_root_microcode_attrs[] = { +#ifdef CONFIG_MICROCODE_LATE_LOADING &dev_attr_reload.attr, +#endif NULL }; -- 2.39.2