lkml.org 
[lkml]   [2018]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
    From
    Date
    On 2/27/2018 11:19 PM, AKASHI Takahiro wrote:
    > Tyler,
    >
    > # I missed catching your patch as its subject doesn't contain arm64.
    >
    > On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote:
    >> Currently on arm64 ESRT memory does not appear to be properly blocked off.
    >> Upon successful initialization, ESRT prints out the memory region that it
    >> exists in like:
    >>
    >> esrt: Reserving ESRT space from 0x000000000a4c1c18 to 0x000000000a4c1cf0.
    >>
    >> But then by dumping /proc/iomem this region appears as part of System RAM
    >> rather than being reserved:
    >>
    >> 08f10000-0deeffff : System RAM
    >>
    >> This causes issues when trying to kexec if the kernel is relocatable. When
    >> kexec tries to execute, this memory can be selected to relocate the kernel to
    >> which then overwrites all the ESRT information. Then when the kexec'd kernel
    >> tries to initialize ESRT, it doesn't recognize the ESRT version number and
    >> just returns from efi_esrt_init().
    >
    > I'm not sure what is the root cause of your problem.
    > Do you have good confidence that the kernel (2nd kernel image in this case?)
    > really overwrite ESRT region?

    According to my debug, yes.
    Using JTAG, I was able to determine that the ESRT memory region was
    getting overwritten by the secondary kernel in
    kernel/arch/arm64/kernel/relocate_kernel.S - specifically the
    "copy_page" line of arm64_relocate_new_kernel()

    > To my best knowledge, kexec is carefully designed not to do such a thing
    > as it allocates a temporary buffer for kernel image and copies it to the
    > final destination at the very end of the 1st kernel.
    >
    > My guess is that kexec, or rather kexec-tools, tries to load the kernel image
    > at 0x8f80000 (or 0x9080000?, not sure) in your case. It may or may not be
    > overlapped with ESRT.
    > (Try "-d" option when executing kexec command for confirmation.)

    With -d, I see

    get_memory_ranges_iomem_cb: 0000000009611000 - 000000000e5fffff : System RAM

    That overlaps the ESRT reservation -
    [ 0.000000] esrt: Reserving ESRT space from 0x000000000b708718 to
    0x000000000b7087f0

    >
    > Are you using initrd with kexec?

    Yes

    >
    > Thanks,
    > -Takahiro AKASHI
    >
    >
    >> This causes an early ioremap leak because
    >> the memory allocated for 'va' is never unmapped. So first fix that error
    >> case to properly unmap 'va' before returning.
    >>
    >> This still leaves ESRT unable to initialize in the kexec'd kernel, so now
    >> mark the ESRT memory block as nomap so that this memory is not treated as
    >> System RAM. With this change I'm able to see that the ESRT data is not
    >> overwritten when running a kexec'd kernel.
    >>
    >> Tyler Baicar (2):
    >> efi/esrt: fix unsupported version initialization failure
    >> efi/esrt: mark ESRT memory region as nomap
    >>
    >> drivers/firmware/efi/esrt.c | 10 +++++++++-
    >> 1 file changed, 9 insertions(+), 1 deletion(-)
    >>
    >> --
    >> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
    >> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
    >> a Linux Foundation Collaborative Project.
    >>
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >


    --
    Jeffrey Hugo
    Qualcomm Datacenter Technologies as an affiliate of Qualcomm
    Technologies, Inc.
    Qualcomm Technologies, Inc. is a member of the
    Code Aurora Forum, a Linux Foundation Collaborative Project.

    \
     
     \ /
      Last update: 2018-02-28 16:40    [W:4.748 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site