Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp9258896rwp; Thu, 20 Jul 2023 01:59:44 -0700 (PDT) X-Google-Smtp-Source: APBJJlFwSlKAm3dccISbYgYPbTkZeoJ5nB410tjq+ykkJn9UneKWqIIehC5P18F1hXEM/9omAi9h X-Received: by 2002:a17:907:320b:b0:997:beca:f9db with SMTP id xg11-20020a170907320b00b00997becaf9dbmr2328379ejb.54.1689843584049; Thu, 20 Jul 2023 01:59:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689843584; cv=none; d=google.com; s=arc-20160816; b=ItBdv/vEt5Tma6Oldn9HxSJDs+AnyvNXzV3V/5+z05zjW2fXEW3kC8wAt2L+Ey1X8G rwRLMTDj31FbFmVO33u0S/7Zn5z6/zJrNR71fEFpb/pSdfaD5x+pmVwZ5VMy3Uz6rRod 6GiEk3UtS/wCZW5VU4iX5NjcHt5kypEoh6Y1rs/5uSSByrs09xfrt7QjGKJh+SAlpKh/ O953yPzDGUNq2iVhT1uyGzoSYyfU4ZNsYCAfojvGUDzLj7lXrz8I/pIVU0ODC5NzEG3U OnnvsC0hTSFuUfapkeIFwWRofZPV5UTA1ZOMboADgCyms68xN+2aYje2YfcLG9x4TWa1 Fxnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LT+DBjjPudnk/MXYjQ8iYkFdpYGojkULcXKfWjUup5w=; fh=Oo7dO6VxEk9P0/+V/M/gItduFh6Ausue26Xfw4gUuUU=; b=p7HLiB9GUhgPLemtaHCDLW1pSMYhtKriTndmLU6cQq3viV63osgz+kD3nLlmFi5ydN Z+mh8/Fogz8iQbKVM1YQHUN4OdHjsIIcwdsGBfm1zoXBjlDZICDFMH1xatAUAiPpW/md tvYpFCJn0djAsQ8zgqo8IUWmbgHFHWXXTX2BbesbXmxf8h5WhecgtTI4yhR7uq0Tz7Ct QZjLvcwpzbl2c0oR7zH4ZaqIJddM0k+8xQR9BQGIJNfuoPyzBupSYuAXIySTSpSsQLoK A+VxrGPVWNt4Rc1h6S51mrAGAAqjMgPLoSLFgmwwY3C2h82o3IZP9EUf/2oKopCKqsX+ UyqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JiEdVC5k; 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 n27-20020a170906689b00b009930d9d6b4csi385744ejr.888.2023.07.20.01.59.14; Thu, 20 Jul 2023 01:59:44 -0700 (PDT) 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=JiEdVC5k; 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 S229888AbjGTI5F (ORCPT + 99 others); Thu, 20 Jul 2023 04:57:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231935AbjGTIge (ORCPT ); Thu, 20 Jul 2023 04:36:34 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E6F62690; Thu, 20 Jul 2023 01:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689842192; x=1721378192; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=pQHREhOcPSz4Z85LUnKLuGoWvYd73M/FkXI+b/m+PDk=; b=JiEdVC5kdmFZnRgTztKZSMww4BOtmy6RO+TQ4ouslAdbEi2gE3pxd3tX L2TlF0v3fupA3BqQcdZL9CpGPi+S7mMemnp66MpgpfDl08x8woGt2E+eN VIk9zIlD3k6UeggLO9a0TVUFy+fBn1sGh7PmEHc6bGl23FamYsZKrysWg ydtTcTjzzY7gAhZ2rPvaB78/eHpcNc6cYpBLIrZ0bziJ5UB/+UmXzrOCF wchZJljCrIQIggESVKBt5m8E/62bNwRM5jvalZYa5mbRfu9h8tCiPsWHY hpTb6whAasbhnYT24R2/5CZDilYqUJa+RDMDep5nkEd8MVWKqvz2GyUoV w==; X-IronPort-AV: E=McAfee;i="6600,9927,10776"; a="397547646" X-IronPort-AV: E=Sophos;i="6.01,218,1684825200"; d="scan'208";a="397547646" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2023 01:36:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10776"; a="970965180" X-IronPort-AV: E=Sophos;i="6.01,218,1684825200"; d="scan'208";a="970965180" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga006.fm.intel.com with ESMTP; 20 Jul 2023 01:36:30 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qMP9B-00Ghit-1e; Thu, 20 Jul 2023 11:36:29 +0300 Date: Thu, 20 Jul 2023 11:36:29 +0300 From: Andy Shevchenko To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Mark Gross , Hans de Goede , Armin Wolf Subject: Re: [RFC PATCH v1] platform/x86: wmi: Do not register driver with invalid GUID Message-ID: References: <20230715211604.1272227-1-pobrn@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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 Wed, Jul 19, 2023 at 07:23:37PM +0000, Barnabás Pőcze wrote: > 2023. július 17., hétfő 13:31 keltezéssel, Andy Shevchenko írta: > > On Mon, Jul 17, 2023 at 11:23:50AM +0000, Barnabás Pőcze wrote: > > > 2023. július 17., hétfő 11:49 keltezéssel, Andy Shevchenko írta: > > > On Sat, Jul 15, 2023 at 09:24:16PM +0000, Barnabás Pőcze wrote: ... > > > > Besides using wrong API (uuid_*() vs. guid_*() one), I don't > > > > > > As far as I can see `guid_parse()` also uses `uuid_is_valid()`, the format is the same. > > > > Then add guid_is_valid() to complete the API. Perhaps with the renaming the > > common part to something else. > > But that would be the exact same function. GUIDs are UUIDs, aren't they? Yes and no. If we want to validate the respective bit for GUID vs. UUID, they will be different. Currently they are the same as validation is relaxed in the kernel. > > > > think we need to validate it here. Why not in file2alias.c? > > > > [...] > > > > > > 1) that seems like a more complicated change (duplicating `uuid_is_valid()`?); > > > 2) that will only check the GUIDs specified by `MODULE_DEVICE_TABLE()`. > > > > > > Arguably the second point is not that significant since most users will indeed > > > use `MODULE_DEVICE_TABLE()`. But I think the first point has some merit. And > > > furthermore, I think this check should be here regardless of whether file2alias.c > > > also contains an equivalent/similar check. > > > > Why do we need it? We never match against wrong GUID from ACPI, since it would > > be very weird ACPI table. > > [...] > > The point is to catch typos in drivers' WMI ID tables. Yes, that's what file2alias is for. We trust modules we build, right? If you don't trust, then we have much bigger problem than this patch tries to address. -- With Best Regards, Andy Shevchenko