Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1256916rwb; Fri, 13 Jan 2023 09:47:02 -0800 (PST) X-Google-Smtp-Source: AMrXdXsyROxyUysbsO/wb6ODgFQ7sGmV7vZ0qlZSIZIacpIpuE4GaQ+KBA4lqVwjff+XSeodAUuh X-Received: by 2002:a05:6a21:3d0e:b0:b2:40a8:abc0 with SMTP id bi14-20020a056a213d0e00b000b240a8abc0mr104792609pzc.40.1673632022713; Fri, 13 Jan 2023 09:47:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673632022; cv=none; d=google.com; s=arc-20160816; b=lSUBrZjEr9BQCstA/EGt1zNAZbB81iWTleoLv+taorP2ZPiKtVaDmSaDv/vfLgM8wv dLlEv583rnFQMEKxGq5a3sjq2ZdYhnSQ3GI9jlnv4XVBZu+5pCY5EtmpA0ArQ8l4Z8aJ I/o3NBo0SQHQfCjbHwhToBH41gnibFzEMJ5C/oVvFnZmIWZDZpd4emnaDNNSUqghunZe vsLEyxrEKJebE7RTrCNQkBdYeRJJNS7uKuMc4+axAKt8jKsR4mwI75rhkyETl8dRvRY6 j7FHNCCSZK9CHsn9ixKxTQFJsTMeMh1SI3wTxdySOUPPEZgBojmrddWqCoGW1WAZATMt 3p4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=N2JMvgbsmDLcdCuvqZMb4QAp08KTiFLrX4U1aY1ABQE=; b=EWtDU1sX8e1v/AIxcOGIlSy05sFfLG3iDchxTl1KMcjov5HefplagKRTKQbRvuIiWG exY38xGrWxd0bKrm7VAudfoksx2v9niWLZcxpzE6rj2mww45po1djP3e835/0L5qb9Hm 9pL6usFSHHdDyxHuQoDcLE9xwXYDv2siBGUyM8cqrTkZM6GEIkCuxSeuCuC7X2gQasyG CXsmiZl25H0/N/CRA69JY5boqz4KsBHyG113wdLp17WoDdcnct3NgGJKZGgXbYLlMV/g 29bT12YobHhMkFOVy2a/6cuRSVYfvU3iL5hm5EDkMdO84iptqcBrxGqqKiAie2v31FzE GmFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mtyt9kqe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 126-20020a630084000000b00499b89917casi21426600pga.782.2023.01.13.09.46.56; Fri, 13 Jan 2023 09:47:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mtyt9kqe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229576AbjAMRnk (ORCPT + 51 others); Fri, 13 Jan 2023 12:43:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229810AbjAMRnJ (ORCPT ); Fri, 13 Jan 2023 12:43:09 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CC028B775 for ; Fri, 13 Jan 2023 09:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673630972; x=1705166972; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=JIm27/Zc/uch3n2kZrsorIE+84Bcpxcmdtm6i5sjCRA=; b=mtyt9kqedLZ2WBsjGhTcwTpwSxyuYotoxpLWfQapcOZ/WKPliIB7YBtI qwPc+e60eleHHnRdc6OSPZKjauLqArRulgVM4lRwFVLgNdkHD7R+P03PG 1L2R9UqgzFGFOa2TfVLejmSCRpNuCRg4T5xl4W5inE2o/RlKIViZgPhaV qjUiDxJUS3QFfUvpogiWYsGVIrP8p7FEf6NBA6sxy9TOVtyh17M/Hcvgh arg0x/gnKQlwmgUIbEwnKQ1sn2RLtKmCP3RyKoo3+HpiUHEJzlW0muZYm tqUPGxvKLqhGsrN9KcQa90eUZbLlynIvLreqeiZdZ623JGTUVGEAr2LUP w==; X-IronPort-AV: E=McAfee;i="6500,9779,10589"; a="304429985" X-IronPort-AV: E=Sophos;i="5.97,214,1669104000"; d="scan'208";a="304429985" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2023 09:29:32 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10589"; a="766089912" X-IronPort-AV: E=Sophos;i="5.97,214,1669104000"; d="scan'208";a="766089912" Received: from araj-ucode.jf.intel.com ([10.23.0.19]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2023 09:29:31 -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 Subject: [PATCH v1 Part2 0/5] Declare safe late loadable microcode Date: Fri, 13 Jan 2023 09:29:15 -0800 Message-Id: <20230113172920.113612-1-ashok.raj@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris & Thomas, Attached is a series that adds support for microcode to declare a minimum revision number that is safe for late loading. Late loading was disabled[1] in 5.19 due to lack of an ability to declare when a microcode is safe for late loading. This series is inspired by recommendations from Thomas [2]. This series is part2 and applies on top of that cleanup series part1[3]. - Move where the warning and tainting is done to the same function. It helps when later patches enable late loading, to issue the warning only when the vendor doesn't support a mechanism for declaring a microcode for safe late loading. - Add meta-data for Intel microcode to specify a minimum revision that the CPU must be on before attempting to load this microcode. - Extend this as a generic mechanism to allow the common infrastructure to permit late loading. - Some CPUs required a wbinvd() to be issued before attempting to load a microcode. These were later addressed via microcode patches. Now there exists a mechanism to declare a minimum revision, those flushes aren't required any longer. - Provide a mechanism to override minrev as a way to bypass during the transition. It is recommended to always use early loading, especially if one is moving to a newer kernel. This is a chicken bit option :) and completely optional. [1] https://lore.kernel.org/lkml/20220524185324.28395-3-bp@alien8.de/ [2] https://lore.kernel.org/linux-kernel/alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de/ [3] https://lore.kernel.org/lkml/20230109153555.4986-1-ashok.raj@intel.com/ Cheers, Ashok 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 Ashok Raj (5): x86/microcode: Move late load warning to the same function that taints kernel x86/microcode/intel: Add minimum required revision to microcode header x86/microcode: Add a generic mechanism to declare support for minrev x86/microcode/intel: Drop wbinvd() from microcode loading x86/microcode: Provide an option to override minrev enforcement arch/x86/include/asm/microcode.h | 4 ++ arch/x86/include/asm/microcode_intel.h | 3 +- arch/x86/kernel/cpu/microcode/core.c | 36 ++++++++++++++--- arch/x86/kernel/cpu/microcode/intel.c | 55 ++++++++++++++++++++------ arch/x86/Kconfig | 7 ++-- 5 files changed, 83 insertions(+), 22 deletions(-) -- 2.34.1