linux-kernel - Re: [PATCH v5 2/3] 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 19:19:01 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Alexander Graf <graf@...zon.com>, Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v5 2/3] ACPI: allow longer device IDs

+Mika, Andy and Hans in case they have something to add

On Mon, Feb 28, 2022 at 12:27 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hey again,
>
> On Sun, Feb 27, 2022 at 1:43 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > Hi Alex,
> >
> > On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote:
> > > > To allow device drivers to match identifiers that exceed the 9 byte
> > > > limit, this simply ups the length to 16, just like it was before the
> > > > aforementioned commit. Empirical testing indicates that this
> > >
> > >
> > > This is only true for 64bit systems where padding automatically bloated
> > > to 9 byte array to 16. I still believe the patch is fine as it is, but
> > > there will be minor .rodata overhead on 32bit targets which you may want
> > > to quantify in the patch description.
> >
> > Good point. So I just tried this out with a 32-bit i686 kernel and the
> > results are the same again for the size of vmlinux. I then ran `objdump
> > --headers` and looked at the size of the .rodata section, where it's
> > also the same. I'm not quite sure what to make of this, as it's not what
> > I was expecting, but I think I tested it right. So maybe we're lucky
> > here?
>
> I tried a little harder to get _some_ difference on 32-bit, and
> managed to get one by doing i386_defconfig and then switching off
> modules to make all M into Y, and then compared sizes:
>
> vmlinux: 25590780 -> 25598972, so a 0.032% increase.
> bzImage: 8698944 -> 8699424, so a 0.0055% increase.
>
> So it does increase, ever so slightly, but a) on 32-bit, and b) a
> super, super tiny amount.
>
> In other words, I still think this patch is very much a-okay. But very
> eager to hear from Rafael on the approach.

Increasing the ACPI_ID_LEN value is fine with me, but the patch
changelog is not entirely accurate.

The ACPI subsystem uses struct acpi_device_id mostly (if not only) for
device ID matching and it is generally used for creating lists of ACPI
device IDs in drivers (and allow/deny lists etc).  The device IDs
extracted from the ACPI tables can be longer than ACPI_ID_LEN.

This means that drivers cannot match device IDs longer than 8
characters (excluding the terminating 0), because the IDs in the lists
used by them for ID matching cannot be longer than this and not
because the ACPI subsystem is limited by that value.