linux-kernel - Re: [PATCH 2/3 v6] ACPI: allow longer device IDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Feb 2022 22:02:43 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-crypto <linux-crypto@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Alexander Graf <graf@...zon.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 2/3 v6] ACPI: allow longer device IDs

On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>
> On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > From: Alexander Graf <graf@...zon.com>
> >
> > 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.