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 21:58:24 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "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>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH 2/3 v6] ACPI: allow longer device IDs

Hi Andy,

On Mon, Feb 28, 2022 at 9:47 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> 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.

Sorry, but no; that seems like a ridiculous requirement. There's
virtual "hardware" out there that is behaving like this. It serves an
important security function. There are no technical downsides to
making the change. It works well.

Yet you're upset that they didn't follow the rules. Indeed, tsk tsk on
Microsoft. But that doesn't mean Linux users should suffer and have
poorer security than Windows.

This kind of thing happens all the time. We do our best to find the
cleanest solution to the problem, and live with it. Linux isn't a
one-hundred-per-cent-by-the-spec operating system, because the things
it works with are often not one-hundred-per-cent-by-the-spec. We even
have quirks tables. It's part of life.

And in this case, the solution is so straightforward that it doesn't
even require anything closely resembling a "hack" or a layering
violation. And that space is already being used (zero filled) anyway
because of struct padding.

This fix is the "clean" way of doing it. Why make this harder than it
needs to be?

Jason