linux-kernel - Re: [PATCH] ACPICA: Drop port I/O validation for some regions

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] [day] [month] [year] [list]

Date:   Fri, 30 Dec 2022 18:50:24 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Mario Limonciello <mario.limonciello@....com>
Cc:     Robert Moore <robert.moore@...el.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Lin Ming <ming.m.lin@...el.com>,
        Len Brown <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
        linux-acpi@...r.kernel.org, devel@...ica.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPICA: Drop port I/O validation for some regions

On Thu, Dec 15, 2022 at 4:51 PM Mario Limonciello
<mario.limonciello@....com> wrote:
>
> Microsoft introduced support in Windows XP for blocking port I/O
> to various regions.  For Windows compatibility ACPICA has adopted
> the same protections and will disallow writes to those
> (presumably) the same regions.
>
> On some systems the AML included with the firmware will issue 4 byte
> long writes to 0x80.  These writes aren't making it over because of this
> blockage. The first 4 byte write attempt is rejected, and then
> subsequently 1 byte at a time each offset is tried. The first at 0x80
> works, but then the next 3 bytes are rejected.
>
> This manifests in bizarre failures for devices that expected the AML to
> write all 4 bytes.  Trying the same AML on Windows 10 or 11 doesn't hit
> this failure and all 4 bytes are written.
>
> Either some of these regions were wrong or some point after Windows XP
> some of these regions blocks have been lifted.
>
> In the last 15 years there doesn't seem to be any reports popping up of
> this error in the Windows event viewer anymore.  There is no documentation
> at Microsoft's developer site indicating that Windows ACPI interpreter
> blocks these regions. Between the lack of documentation and the fact that
> the writes actually do work in Windows 10 and 11, it's quite likely
> Windows doesn't actually enforce this anymore.
>
> So to help the issue, only enforce Windows XP specific entries if the
> latest _OSI supported is Windows XP. Continue to enforce the
> ALWAYS_ILLEGAL entries.
>
> Link: https://github.com/acpica/acpica/pull/817
> Fixes: 7f0719039085 ("ACPICA: New: I/O port protection")
> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> ---
>  drivers/acpi/acpica/hwvalid.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpica/hwvalid.c b/drivers/acpi/acpica/hwvalid.c
> index 915b26448d2c..0d392e7b0747 100644
> --- a/drivers/acpi/acpica/hwvalid.c
> +++ b/drivers/acpi/acpica/hwvalid.c
> @@ -23,8 +23,8 @@ acpi_hw_validate_io_request(acpi_io_address address, u32 bit_width);
>   *
>   * The table is used to implement the Microsoft port access rules that
>   * first appeared in Windows XP. Some ports are always illegal, and some
> - * ports are only illegal if the BIOS calls _OSI with a win_XP string or
> - * later (meaning that the BIOS itelf is post-XP.)
> + * ports are only illegal if the BIOS calls _OSI with nothing newer than
> + * the specific _OSI strings.
>   *
>   * This provides ACPICA with the desired port protections and
>   * Microsoft compatibility.
> @@ -145,7 +145,8 @@ acpi_hw_validate_io_request(acpi_io_address address, u32 bit_width)
>
>                         /* Port illegality may depend on the _OSI calls made by the BIOS */
>
> -                       if (acpi_gbl_osi_data >= port_info->osi_dependency) {
> +                       if (port_info->osi_dependency == ACPI_ALWAYS_ILLEGAL ||
> +                           acpi_gbl_osi_data == port_info->osi_dependency) {
>                                 ACPI_DEBUG_PRINT((ACPI_DB_VALUES,
>                                                   "Denied AML access to port 0x%8.8X%8.8X/%X (%s 0x%.4X-0x%.4X)\n",
>                                                   ACPI_FORMAT_UINT64(address),
> --

Applied as 6.3 material, thanks!