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
| ||
|
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
Powered by blists - more mailing lists