lkml.org 
[lkml]   [2019]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[tip: x86/urgent] x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage
    The following commit has been merged into the x86/urgent branch of tip:

    Commit-ID: af164898482817a1d487964b68f3c21bae7a1beb
    Gitweb: https://git.kernel.org/tip/af164898482817a1d487964b68f3c21bae7a1beb
    Author: Dave Young <dyoung@redhat.com>
    AuthorDate: Wed, 04 Dec 2019 15:52:33 +08:00
    Committer: Ingo Molnar <mingo@kernel.org>
    CommitterDate: Wed, 04 Dec 2019 11:15:30 +01:00

    x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage

    Michael Weiser reported that he got this error during a kexec rebooting:

    esrt: Unsupported ESRT version 2904149718861218184.

    The ESRT memory stays in EFI boot services data, and it was reserved
    in kernel via efi_mem_reserve(). The initial purpose of the reservation
    is to reuse the EFI boot services data across kexec reboot. For example
    the BGRT image data and some ESRT memory like Michael reported.

    But although the memory is reserved it is not updated in the X86 E820 table,
    and kexec_file_load() iterates system RAM in the IO resource list to find places
    for kernel, initramfs and other stuff. In Michael's case the kexec loaded
    initramfs overwrote the ESRT memory and then the failure happened.

    Since kexec_file_load() depends on the E820 table being updated, just fix this
    by updating the reserved EFI boot services memory as reserved type in E820.

    Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are
    bypassed in the reservation code path because they are assumed as reserved.

    But the reservation is still needed for multiple kexec reboots,
    and it is the only possible case we come here thus just drop the code
    chunk, then everything works without side effects.

    On my machine the ESRT memory sits in an EFI runtime data range, it does
    not trigger the problem, but I successfully tested with BGRT instead.
    both kexec_load() and kexec_file_load() work and kdump works as well.

    [ mingo: Edited the changelog. ]

    Reported-by: Michael Weiser <michael@weiser.dinsnail.net>
    Tested-by: Michael Weiser <michael@weiser.dinsnail.net>
    Signed-off-by: Dave Young <dyoung@redhat.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: kexec@lists.infradead.org
    Cc: linux-efi@vger.kernel.org
    Link: https://lkml.kernel.org/r/20191204075233.GA10520@dhcp-128-65.nay.redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    ---
    arch/x86/platform/efi/quirks.c | 6 ++----
    1 file changed, 2 insertions(+), 4 deletions(-)

    diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
    index 7675cf7..f8f0220 100644
    --- a/arch/x86/platform/efi/quirks.c
    +++ b/arch/x86/platform/efi/quirks.c
    @@ -260,10 +260,6 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
    return;
    }

    - /* No need to reserve regions that will never be freed. */
    - if (md.attribute & EFI_MEMORY_RUNTIME)
    - return;
    -
    size += addr % EFI_PAGE_SIZE;
    size = round_up(size, EFI_PAGE_SIZE);
    addr = round_down(addr, EFI_PAGE_SIZE);
    @@ -293,6 +289,8 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
    early_memunmap(new, new_size);

    efi_memmap_install(new_phys, num_entries);
    + e820__range_update(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED);
    + e820__update_table(e820_table);
    }

    /*
    \
     
     \ /
      Last update: 2019-12-04 11:22    [W:3.733 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site