Skip to content
  • Lv Zheng's avatar
    ACPICA: Utilities: split IO address types from data type models. · 27b22d01
    Lv Zheng authored
    commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream.
    
    ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451
    
    It is reported that on a physically 64-bit addressed machine, 32-bit kernel
    can trigger crashes in accessing the memory regions that are beyond the
    32-bit boundary. The region field's start address should still be 32-bit
    compliant, but after a calculation (adding some offsets), it may exceed the
    32-bit boundary. This case is rare and buggy, but there are real BIOSes
    leaked with such issues (see References below).
    
    This patch fixes this gap by always defining IO addresses as 64-bit, and
    allows OSPMs to optimize it for a real 32-bit machine to reduce the size of
    the internal objects.
    
    Internal acpi_physical_address usages in the structures that can be fixed
    by this change include:
     1. struct acpi_object_region:
        acpi_physical_address		address;
     2. struct acpi_address_range:
        acpi_physical_address		start_address;
        acpi_physical_address		end_address;
     3. struct acpi_mem_space_context;
        acpi_physical_address		address;
     4. struct acpi_table_desc
        acpi_physical_address		address;
    See known issues 1 for other usages.
    
    Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer
    from same problem, so this patch changes it accordingly.
    
    For iasl, it will enforce acpi_physical_address as 32-bit to generate
    32-bit OSPM compatible tables on 32-bit platforms, we need to define
    ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.
    
    Known issues:
     1. Cleanup of mapped virtual address
       In struct acpi_mem_space_context, acpi_physical_address is used as a virtual
       address:
        acpi_physical_address                   mapped_physical_address;
       It is better to introduce acpi_virtual_address or use acpi_size instead.
       This patch doesn't make such a change. Because this should be done along
       with a change to acpi_os_map_memory()/acpi_os_unmap_memory().
       There should be no functional problem to leave this unchanged except
       that only this structure is enlarged unexpectedly.
    
    Link: https://github.com/acpica/acpica/commit/aacf863c
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501
    
    
    Reported-and-tested-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
    Reported-and-tested-by: default avatarSial Nije <sialnije@gmail.com>
    Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
    Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    27b22d01