Message-ID: <1f03865f-2d22-8ba1-a276-a6b49d7c14de@codeaurora.org>
Date:   Wed, 28 Feb 2018 08:39:42 -0700
From:   Jeffrey Hugo <jhugo@...eaurora.org>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Tyler Baicar <tbaicar@...eaurora.org>,
        ard.biesheuvel@...aro.org, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org, sgoel@...eaurora.org,
        timur@...eaurora.org
Subject: Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

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@...r.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.

Powered by blists - more mailing lists