efi: Correct address handling with ACPI tables
authorSimon Glass <sjg@chromium.org>
Wed, 1 Dec 2021 16:02:42 +0000 (09:02 -0700)
committerSimon Glass <sjg@chromium.org>
Tue, 25 Jan 2022 18:44:36 +0000 (11:44 -0700)
The current EFI implementation confuses pointers and addresses. Normally
we can get away with this but in the case of sandbox it causes failures.

Despite the fact that efi_allocate_pages() returns a u64, it is actually
a pointer, not an address. Add special handling to avoid a crash when
running 'bootefi hello'.

Signed-off-by: Simon Glass <sjg@chromium.org>
lib/efi_loader/efi_acpi.c

index f2b55b4..2ddc350 100644 (file)
@@ -8,6 +8,7 @@
 #include <common.h>
 #include <efi_loader.h>
 #include <log.h>
+#include <mapmem.h>
 #include <acpi/acpi_table.h>
 
 static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
@@ -22,6 +23,7 @@ efi_status_t efi_acpi_register(void)
        /* Map within the low 32 bits, to allow for 32bit ACPI tables */
        u64 acpi = U32_MAX;
        efi_status_t ret;
+       ulong addr;
 
        /* Reserve 64kiB page for ACPI */
        ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
@@ -34,7 +36,8 @@ efi_status_t efi_acpi_register(void)
         * a 4k-aligned address, so it is safe to assume that
         * write_acpi_tables() will write the table at that address.
         */
-       write_acpi_tables((ulong)acpi);
+       addr = map_to_sysmem((void *)(ulong)acpi);
+       write_acpi_tables(addr);
 
        /* And expose them to our EFI payload */
        return efi_install_configuration_table(&acpi_guid,