On Mon, Feb 28, 2022 at 10:02:43PM +0100, Ard Biesheuvel wrote: > On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > > > On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > > > > > From: Alexander Graf <graf@xxxxxxxxxx> > > > > > > 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