linux-kernel - Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Mar 2018 12:56:38 -0500
From:   Tyler Baicar <tbaicar@...eaurora.org>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Jeffrey Hugo <jhugo@...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

Hello,

On 2/28/2018 9:50 PM, AKASHI Takahiro wrote:
> Hi,
>
> On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote:
>> 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
> To make the things clear, can you show me, if possible, the followings:
I have attached all of these:
> * dmesg
dmesg.txt: Main kernel dmesg logs which shows ESRT enabling properly
kexec_dmesg.txt: Kexec'd kernel dmesg logs showing ESRT invalid version and the 
memory leak warning
> * /proc/iomem
iomem.txt
> * the output from "kexec -d", particularly the last part like
>      kexec_load: entry = 0x411d7660 flags = 0xb70000
>      nr_segments = 3
>      segment[0].buf   = 0xffff86613010
>      segment[0].bufsz = 0x10e9b48
>      segment[0].mem   = 0x40080000
>      segment[0].memsz = 0x1156000
>      segment[1].buf   = 0xffff86211010
>      segment[1].bufsz = 0x20e
>      segment[1].mem   = 0x411d6000
>      segment[1].memsz = 0x1000
>      segment[2].buf   = 0x5045420
>      segment[2].bufsz = 0x31b8
>      segment[2].mem   = 0x411d7000
>      segment[2].memsz = 0x4000
kexec_output.txt

Thanks,
Tyler

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


View attachment "dmesg.txt" of type "text/plain" (91649 bytes)

View attachment "iomem.txt" of type "text/plain" (15058 bytes)

View attachment "kexec_dmesg.txt" of type "text/plain" (98205 bytes)

View attachment "kexec_output.txt" of type "text/plain" (12024 bytes)