Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5875618rwb; Mon, 14 Nov 2022 10:39:49 -0800 (PST) X-Google-Smtp-Source: AA0mqf5q8QJn5OeRvk83jvXZUycyAjJ8BPpZow/cIEoAJ1f8/qeyyEN+rJp/mHCqQ/6pWWU8LJBO X-Received: by 2002:a17:906:4e54:b0:78d:a30f:3f3a with SMTP id g20-20020a1709064e5400b0078da30f3f3amr11232428ejw.386.1668451189299; Mon, 14 Nov 2022 10:39:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668451189; cv=none; d=google.com; s=arc-20160816; b=ZNb88LToxDki3iSLdc2igjD+fSodz560TsnWJOXPRRmnw2xAdX8SoWkFqMTJe7wUtw AkNAo29bouRRAGh+Ok5bxNNabARZlyR+Tq8BaNyqqsUW4ZXqxdK0kZH7KH4eHujZ/wc5 R7Bqgzh0VOZdKMYG3Ce3KH9SwN9VIubsXqY7zvPlYb30giGpLOQkay/VOpBxp7P6Xh9o V7V2KgbgC2IoHVztZ/cDht/ziZaBbsu3tpEcfk7m/yujVFPHUZW+WgUwkJ37/0HBO5xS Vgi0z19powt8ezqw+RduxDRlIrW65wf+XE5XsHi6z8VnTSPdop5z/mYbzcmtR9HA3pPA Vl3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=5OvWYQ3ErGB0/tNbqIItEth5bCdVvxBHTm7k6die9qA=; b=WgGh6GjdqbuQdncjIQeTEGRsVRQSYrURCJgMaALU5L+AWT3MvfTy2nCEMkjbYZUef5 fue2fyRI3Q6ZFBdJr9EYXwjZHHUXX34TpEwxWKaqKPCrOxkH9R1Su15QRhDiP+rBCBti /WcTHHjdIRia+4rFc9ZZv389f+noiqGkPr2dsy08YxbnmLCXercvST5EmsjETDGv+MtC ofyPvFlckBO2ejx3QZeoqc7ZNhmRPJ6vLc2R3+AaRNaAd00JAObqb0QXDqmNLaXYRLwY Vnv/h/PJ8ZMOXgu7/YJw4opT+PFIc3Ja/cRo7MXluS1q5wsOUfCUBUd5z6xo/P0TzjAX ztDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="GMMGdN/P"; 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 gs16-20020a1709072d1000b0078db3f08a6bsi9888873ejc.720.2022.11.14.10.39.27; Mon, 14 Nov 2022 10:39:49 -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="GMMGdN/P"; 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 S238311AbiKNSOR (ORCPT + 88 others); Mon, 14 Nov 2022 13:14:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238255AbiKNSNr (ORCPT ); Mon, 14 Nov 2022 13:13:47 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D33CE2A956; Mon, 14 Nov 2022 10:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668449626; x=1699985626; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=hxEkQbuK0QMuKu1CziKwj4cVOaJutws2LHKgFPOQBT8=; b=GMMGdN/PTsbha/j+36bozMmjkN8hLbYbFoSt0GnlKQXNagAUirKY3+ox SDNOtoqYVyqQ7dM8bDe6NX/WPLTVKX0lvVUkpqADu1ywkjUFiDvWLL90F HuA8pOU3pJ8sadcOMgm9SV5/UP0I7gZVCVMB+Cw+5vPBjNd5wJS+iku5I mrAvRAF5fsDfSqM7Yydlm04XWKmoU0HI8E/CPnBPbFIavWwiaVLXu3nQn 9o+RGJuPdEirNN2eaj+qB3HkkuaHsmfebGM0pjiK+MLIDExr3WHos7vUi HCO7NJWvzdyjtN/Eto619tWgoGMD0XvJH3XGdR/IVEyswKZfEHQy0qCoP A==; X-IronPort-AV: E=McAfee;i="6500,9779,10531"; a="291756158" X-IronPort-AV: E=Sophos;i="5.96,164,1665471600"; d="scan'208";a="291756158" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2022 10:13:46 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10531"; a="781028079" X-IronPort-AV: E=Sophos;i="5.96,164,1665471600"; d="scan'208";a="781028079" Received: from satyanay-mobl1.amr.corp.intel.com (HELO [10.209.114.162]) ([10.209.114.162]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2022 10:13:45 -0800 Message-ID: <45aa0f69-2523-3cba-8f41-b1351f16b78f@intel.com> Date: Mon, 14 Nov 2022 10:13:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs entry Content-Language: en-US To: Borislav Petkov , Ashok Raj Cc: "gregkh@linuxfoundation.org" , Thiago Macieira , "Luck, Tony" , "Joseph, Jithu" , "hdegoede@redhat.com" , "markgross@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , "patches@lists.linux.dev" , "Shankar, Ravi V" , "Jimenez Gonzalez, Athenas" , "Mehta, Sohil" References: <20221021203413.1220137-1-jithu.joseph@intel.com> <20221107225323.2733518-1-jithu.joseph@intel.com> <20221107225323.2733518-13-jithu.joseph@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,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 On 11/13/22 07:58, Borislav Petkov wrote: > On Sun, Nov 13, 2022 at 07:15:03AM -0800, Ashok Raj wrote: >> Do you expect the /lib/firmware/intel/ifs_0/ to contain *ONLY* files for >> this platform? For microcode we have everything in the public release >> included here. > Same as microcode, as I said further down in my mail: > > "And, ofcourse it would check the format of that string against family, > model, stepping and sequence number (btw this way you drop your > limitation of 256 for the sequence number which you don't really need > either)." Maybe dumb question, but what's the point of even checking the filenames? They're meaningless. Let's say we're on model=1,family=2,stepping=3. We try to load test #99: 01-02-03-99.scan The kernel goes and does the sscanf() and checks "01", "02", etc... Everything is fine. The header checks on the .scan file are OK. Life is good. No harm no foul. Then, some dastardly user does this: mv 04-05-06-99.scan 01-02-03-99.scan Taking an evil model=4,family=5,stepping=6 .scan file and trying to load it. It will *pass* the sscanf() checks. But, will fail the metadata checks. The kernel wasted the effort of requesting the file, but there's no harm to anything. So, what's the point of the sscanf() to check the *filename* other than saving some potentially expensive request_firmware() calls?