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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85903C2D0E4 for ; Tue, 17 Nov 2020 09:19:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF17824655 for ; Tue, 17 Nov 2020 09:19:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="qkU3HYeN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727003AbgKQJSq (ORCPT ); Tue, 17 Nov 2020 04:18:46 -0500 Received: from mail.skyhub.de ([5.9.137.197]:45382 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726035AbgKQJSp (ORCPT ); Tue, 17 Nov 2020 04:18:45 -0500 Received: from zn.tnic (p200300ec2f1013008dee3addeed0ca22.dip0.t-ipconnect.de [IPv6:2003:ec:2f10:1300:8dee:3add:eed0:ca22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1D5C01EC03D5; Tue, 17 Nov 2020 10:18:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1605604724; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=rbikV7BXkOw+k4+ExJQ238GNgrFHk9HjzHfX7ZZpv4U=; b=qkU3HYeNhT2a0N0WA4BP2rvjX8OoVJ9HcRc4S+/F4r9aF4g2AZUJvBxT+73uiaXlNHsz6B G8lg97nc847JuWrg6apInBM7UJjNRHI1lavgpU8HwYtgOK2aATntYlqAnBP4WOk/VEfsox WkrkWUOHYr/q1blerhad0xsNi9chnFc= Date: Tue, 17 Nov 2020 10:18:37 +0100 From: Borislav Petkov To: Chen Yu Cc: Andy Lutomirski , Ashok Raj , "Hansen, Dave" , Len Brown , "Rafael J. Wysocki" , Tony Luck , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][v2] x86/microcode/intel: check cpu stepping and processor flag before saving microcode Message-ID: <20201117091837.GA5719@zn.tnic> References: <20201113015923.13960-1-yu.c.chen@intel.com> <20201116122735.GA1131@zn.tnic> <20201117022518.GA17555@chenyu-office.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201117022518.GA17555@chenyu-office.sh.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 17, 2020 at 10:25:18AM +0800, Chen Yu wrote: > If I understand correctly, the only place that invokes > save_mc_for_early() is in generic_load_microcode(). While in > generic_load_microcode() only microcode has a newer version will be > saved by checking has_newer_microcode(), and this function leverages > find_matching_signature() to check if the candidate is of the same > signature. So when it comes to save_microcode_patch(), the signature > already matches. In case save_mc_for_early() will be invoked by other > function in the future, it is okay to add this check too. The important aspect is that you need to save in intel_ucode_patch the *exact* patch for the CPU you're running on. The code above that in save_microcode_patch() adds patches of the same family/model but *not* same stepping to the microcode cache in case we want to support mixed-stepping revisions. And those you don't need to check for exact match. What I'd like, however, is to get rid of that mixed-stepping support - which is total nonsense anyway, if you ask me - and that would simplify the code a *lot* more. Thx for testing. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette