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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C750BC433EF for ; Mon, 28 Feb 2022 21:28:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230133AbiB1V2k (ORCPT ); Mon, 28 Feb 2022 16:28:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229795AbiB1V2j (ORCPT ); Mon, 28 Feb 2022 16:28:39 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E2C2125C87; Mon, 28 Feb 2022 13:28:00 -0800 (PST) X-IronPort-AV: E=McAfee;i="6200,9189,10272"; a="240402952" X-IronPort-AV: E=Sophos;i="5.90,144,1643702400"; d="scan'208";a="240402952" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2022 13:28:00 -0800 X-IronPort-AV: E=Sophos;i="5.90,144,1643702400"; d="scan'208";a="708807672" Received: from smile.fi.intel.com ([10.237.72.59]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2022 13:27:57 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nOnXx-009bWI-8V; Mon, 28 Feb 2022 23:27:09 +0200 Date: Mon, 28 Feb 2022 23:27:08 +0200 From: Andy Shevchenko To: Ard Biesheuvel Cc: "Jason A. Donenfeld" , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-crypto , ACPI Devel Maling List , Alexander Graf , Mika Westerberg , Hans de Goede , Len Brown , Greg Kroah-Hartman Subject: Re: [PATCH 2/3 v6] ACPI: allow longer device IDs Message-ID: References: <20220228183355.9090-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Feb 28, 2022 at 10:02:43PM +0100, Ard Biesheuvel wrote: > On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko wrote: > > > > On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld wrote: > > > > > > From: Alexander Graf > > > > > > We create a list of ACPI "PNP" IDs which contains _HID, _CID, and CLS > > > entries of the respective devices. However, when making structs for > > > matching, we squeeze those IDs into acpi_device_id, which only has 9 > > > bytes space to store the identifier. The subsystem actually captures the > > > full length of the IDs, and the modalias has the full length, but this > > > struct we use for matching is limited. It originally had 16 bytes, but > > > was changed to only have 9 in 6543becf26ff ("mod/file2alias: make > > > modalias generation safe for cross compiling"), presumably on the theory > > > that it would match the ACPI spec so it didn't matter. > > > > > Unfortunately, while most people adhere to the ACPI specs, Microsoft > > > decided that its VM Generation Counter device [1] should only be > > > identifiable by _CID with a value of "VM_Gen_Counter", which is longer > > > than 9 characters. > > > > Then why do we not see the ECR from somebody to update the spec or to > > fix MS' abuse of it? > > I believe _this_ should be the prerequisite to the proposed change. > > What exactly are you suggesting here? That the contributor of this > patch joins the UEFI forum as an individual adopter in order to get > the ACPI spec updated before we can advance with this patch? Or that > he works with Microsoft to get them to refrain from violating it? > > I don't think that is reasonable or realistic. The kernel is already > riddled with UEFI and ACPI quirks that are only there because some > teams at MS don't take the ACPI spec too literally (which is why they > have their own AML compiler, for one), and PC vendors only care about > the Windows sticker, so they don't care about the ACPI spec either. > > So I don't think this is the right time to get pedantic about this. > Our ACPI subsystem already deals with CIDs that are longer than 8 > characters (which are btw permitted by the ACPI spec for bus topology > related metadata), the only thing being changed here is the ability to > actually match against such identifiers. My point is that this is clear abuse of the spec and: 1) we have to enable the broken, because it is already in the wild with the comment that this is an issue AND 2) issue an ECR / work with MS to make sure they understand the problem. This can be done in parallel. What I meant as a prerequisite is to start doing 2) while we have 1) on table. -- With Best Regards, Andy Shevchenko