Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1855835rwb; Thu, 19 Jan 2023 16:49:40 -0800 (PST) X-Google-Smtp-Source: AMrXdXudh/OtAxV8TiZXj6sJfUDOr/H0UpPpcL7oWuFQqnPr4IA1720ObzFExdPkTtgXUUxLJc7c X-Received: by 2002:a05:6a20:7d8d:b0:a9:e225:6f7b with SMTP id v13-20020a056a207d8d00b000a9e2256f7bmr17390055pzj.0.1674175780464; Thu, 19 Jan 2023 16:49:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674175780; cv=none; d=google.com; s=arc-20160816; b=E4bQGQ9TI7TK+AwNFDkF1VEwFMrgto2izDO0bbARRN41K0BAxJEKVTbGUba7TKtylG d5Z4o095hA9JgvoVxPWk7uPon5XrBSjxavu0VqypsE2NyXOTSyWECNIqqUVxQ+ecy+vL GS0lj2zXa/ldYglqfm8ihwsTOVvIxF2JYBbqm/bafJYsf9NfYb4tvbSqmD7nhZkZPkNI P8wlsVAuvrwHffFJXCol79RJoQWsTwP5jLbIBAwT9n+VSSouEVQYme5hZ2cD2YsKOAbz fnZjhCyB09ulTes/6MuGHLK5YAJKEhH6rxim9+knvSJUWUXfQBhBqYDpd1SFSokdp2gm bnxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=G8LqwXu5N/XTWGs4+/Z4tXzItJ00/1ZndX0/k1rrP8E=; b=KvevDsFyyXRLxTzza/4uShot7NGW7jEf39x5rqznW+Uy4BkCZWLvHAF3EgpV6O+kqt QtKU/aHafLbDMf66zztfn8YYRFqUSTum2qGHUg9HGgoKTMyXElUHOXls1gCJhTN3X5lA xVmQaqGkkv0NgnCqofvvwKRlVN8fzXUmkRyxOLafR2jHt7xLGwkhYqno0zJ5xK7aPtP9 WtQ7Q/sJHfh4sZC+QhMV/hmKoz1Cl8QbRjyGrmL73fEkldJ0/lTvYyVLP9ACj+sKmzD6 Nwns9qZ/+W8x1sipYgy6XTKPFVyFi5c8dNOoqAN56TgHYAFUQ5nZL3X8x1/fiDDwnAd+ Idhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=eKlEnIkT; dkim=neutral (no key) header.i=@linutronix.de; 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=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j69-20020a638048000000b004b980d584eesi6218127pgd.49.2023.01.19.16.49.34; Thu, 19 Jan 2023 16:49:40 -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=@linutronix.de header.s=2020 header.b=eKlEnIkT; dkim=neutral (no key) header.i=@linutronix.de; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229492AbjATAPL (ORCPT + 48 others); Thu, 19 Jan 2023 19:15:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229471AbjATAPJ (ORCPT ); Thu, 19 Jan 2023 19:15:09 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DE01A296B for ; Thu, 19 Jan 2023 16:15:08 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1674173705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=G8LqwXu5N/XTWGs4+/Z4tXzItJ00/1ZndX0/k1rrP8E=; b=eKlEnIkTdKjtGT69E8Z6QJ7MFm40+hR7iuL6Bd/6NHrr4anJHpV/P+NrwoXigo9dWxsLSb u7w47EdwWcROXZAcyZx9c0XF6t46aCN3srO3K+4SNKMgbDeLkHLhwdux4l+0B6TmbkwnXd DIak/t5TIyoA6CoJYbFoGsb54z5Ld2M48vJyQBCezfrRbq63h3qIck1gtcOeRePleEnKY+ YVJ0V4Lb5pQAkm6G/LOqjkOOy8DFtNCCw0F+cKW7sKde8559IlwaJXHgrS+swnUhTPXMfp oApjcvqZj2mzhXf/dkeaqktSVET42KMsGp38u1v6nhL6zUea4XGzugsoebvytA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1674173705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=G8LqwXu5N/XTWGs4+/Z4tXzItJ00/1ZndX0/k1rrP8E=; b=1/LT9TlvZ1s6nN1Ct1cf9Fc9ceE6t8k/2mGxLjs/Wu7vSnhus6qeB7Kk+N5hkxOhcREYKa rJrSTib8/3z7owCg== To: Ashok Raj , Borislav Petkov Cc: Ashok Raj , Tony Luck , LKML , x86 , Ingo Molnar , 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: Re: [PATCH v1 Part2 3/5] x86/microcode: Add a generic mechanism to declare support for minrev In-Reply-To: <20230113172920.113612-4-ashok.raj@intel.com> References: <20230113172920.113612-1-ashok.raj@intel.com> <20230113172920.113612-4-ashok.raj@intel.com> Date: Fri, 20 Jan 2023 01:15:04 +0100 Message-ID: <87y1pygiyf.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS 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 Ashok! On Fri, Jan 13 2023 at 09:29, Ashok Raj wrote: > Intel microcode adds some meta-data to report a minimum required revision > before this new microcode can be safely late loaded. There are no generic s/this new microcode/a new microcode revision/ Changelogs are not restricted by twitter posting rules. > mechanism to declare support for all vendors. > > Add generic support to microcode core to declare such support, this allows > late-loading to be permitted in those architectures that report support > for safe late loading. > > Late loading has added support for > > - New images declaring a required minimum base version before a late-load > is performed. > > Tainting only happens on architectures that don't support minimum required > version reporting. > > Add a new variable in microcode_ops to allow an architecture to declare > support for safe microcode late loading. > @@ -487,13 +488,22 @@ static ssize_t reload_store(struct device *dev, > if (ret) > goto put; > > + safe_late_load = microcode_ops->safe_late_load; > + > + /* > + * If safe loading indication isn't present, bail out. > + */ > + if (!safe_late_load) { > + pr_err("Attempting late microcode loading - it is dangerous and taints the kernel.\n"); > + pr_err("You should switch to early loading, if possible.\n"); > + ret = -EINVAL; > + goto put; > + } > + > tmp_ret = microcode_ops->request_microcode_fw(bsp, µcode_pdev->dev); > if (tmp_ret != UCODE_NEW) > goto put; > > - pr_err("Attempting late microcode loading - it is dangerous and taints the kernel.\n"); > - pr_err("You should switch to early loading, if possible.\n"); > - Why are you not moving the pr_err()s right away (in 1/5) to the place where you move it now? > mutex_lock(µcode_mutex); > ret = microcode_reload_late(); > mutex_unlock(µcode_mutex); > @@ -501,11 +511,16 @@ static ssize_t reload_store(struct device *dev, > put: > cpus_read_unlock(); > > + /* > + * Only taint if a successful load and vendor doesn't support > + * safe_late_load > + */ > + if (!(ret && safe_late_load)) > + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); The resulting code is undecodable garbage. Whats worse is that the existing logic in this code is broken already. #1 ssize_t ret = 0; This 'ret = 0' assignment is pointless as ret is immediately overwritten by the next line: ret = kstrtoul(buf, 0, &val); if (ret) return ret; if (val != 1) return size; Now this is really useful. If the value is invalid, i.e. it causes the function to abort immediately it returns 'size' which means the write was successful. Oh well. Now lets look at a few lines further down: #2 ssize_t ret = 0; ... ret = check_online_cpus(); if (ret) goto put; ... put: ... add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); ... return ret; Why are we tainting the kernel when there was absolutely ZERO action done here? All what check_online_cpus() figured out was that not enough CPUs were online, right? That justfies a error return, but the taint is bogus, no? The next bogosity is: ssize_t ret = 0; ... tmp_ret = microcode_ops->request_microcode_fw(bsp, µcode_pdev->dev); if (tmp_ret != UCODE_NEW) goto put; ... put: ... add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); if (ret == 0) ret = size; return ret; IOW, the microcode request can fail for whatever reason and the return value is unconditionally 'size' which means the write to the sysfs file is successfull. #3 Not to talk about the completely broken error handling in the actual microcode loading case in __reload_late()::wait_for_siblings code path. Maybe more #... How does any of this make sense and allows sensible scripting of this interface? Surely you spent several orders of magnitude more time to stare at this code than I did during this review, no? Now instead of noticing and fixing any of this nonsense you are duct taping this whole safe_late_load handling into that mess to make it even more incomprehensible. If you expected an alternative patch here, then I have to disappoint you. I'm not presenting you the proper solution this time on a silver tablet because I'm in the process of taming my 'let me fix this for you' reflex to prepare for my retirement some years down the road. But you should have enough hints to fix all of this for real, right? Thanks, tglx