Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
Ard, On Wed, Mar 07, 2018 at 07:55:34PM +, Ard Biesheuvel wrote: > (+ James) > > Hello Akashi, > > On 6 March 2018 at 09:00, AKASHI Takahiro wrote: > > Tyler, Jeffrey, > > > > On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyler Baicar wrote: > >> On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: > >> >Tyler, Jeffrey, > >> > > >> >[Note: This issue takes place in kexec, not kdump. So to be precise, > >> >it is not the same phenomenon as what I addressed in [1],[2]: > >> > [1] > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557254.html > >> > [2] > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553098.html > >> >] > >> > > >> >On Thu, Mar 01, 2018 at 12:56:38PM -0500, Tyler Baicar wrote: > >> >>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 0x0a4c1c18 to > >> >>0x0a4c1cf0. > >> >> > >> >>But then by dumping /proc/iomem this region appears as part of > >> >>System RAM > >> >>rather than being reserved: > >> >> > >> >>08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : > >> System RAM > >> > >> That overlaps the ESRT reservation - > >> [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to > >> 0x0b7087f0 > >> > >> >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: > >> >Many thanks. > >> >According to the data, ESRT was overwritten by initrd, not the kernel > >> >image. > >> >It doesn't matter to you though :) > >> > > >> >The solution would be, as Ard suggested, that more information be > >> >added to /proc/iomem. > >> >I'm going to fix the issue as quickly as possible. > >> Great, thank you!! Please add us to the fix and we will gladly test it out. > > > > I have created a workaround patch, attached below, as a kind of PoC. > > Can you give it a go, please? > > You need another patch for kexec-tools, too. See > > https:/git.linaro.org/people/takahiro.akashi/kexecl-tools.git arm64/resv_mem > > > > Thanks for putting this together. Some questions below. > > > With this patch, extra entries for firmware-reserved memory resources, > > which means any regions that are already reserved before > > arm64_memblock_init(), > > or specifically efi/acpi tables in this case, are added to /proc/iomem. > > > > $ cat /proc/iomem (on my qemu+edk2 execution) > > ... > > 4000-5871 : System RAM > > 4008-40f1 : Kernel code > > 4104-411e9fff : Kernel data > > 5440-583f : Crash kernel > > 5859-585e : reserved > > 5870-5871 : reserve
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
(+ James) Hello Akashi, On 6 March 2018 at 09:00, AKASHI Takahiro wrote: > Tyler, Jeffrey, > > On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyler Baicar wrote: >> On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: >> >Tyler, Jeffrey, >> > >> >[Note: This issue takes place in kexec, not kdump. So to be precise, >> >it is not the same phenomenon as what I addressed in [1],[2]: >> > [1] >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557254.html >> > [2] >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553098.html >> >] >> > >> >On Thu, Mar 01, 2018 at 12:56:38PM -0500, Tyler Baicar wrote: >> >>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 0x0a4c1c18 to >> >>0x0a4c1cf0. >> >> >> >>But then by dumping /proc/iomem this region appears as part of System >> >>RAM >> >>rather than being reserved: >> >> >> >>08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System >> RAM >> >> That overlaps the ESRT reservation - >> [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to >> 0x0b7087f0 >> >> >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: >> >Many thanks. >> >According to the data, ESRT was overwritten by initrd, not the kernel image. >> >It doesn't matter to you though :) >> > >> >The solution would be, as Ard suggested, that more information be >> >added to /proc/iomem. >> >I'm going to fix the issue as quickly as possible. >> Great, thank you!! Please add us to the fix and we will gladly test it out. > > I have created a workaround patch, attached below, as a kind of PoC. > Can you give it a go, please? > You need another patch for kexec-tools, too. See > https:/git.linaro.org/people/takahiro.akashi/kexecl-tools.git arm64/resv_mem > Thanks for putting this together. Some questions below. > With this patch, extra entries for firmware-reserved memory resources, > which means any regions that are already reserved before > arm64_memblock_init(), > or specifically efi/acpi tables in this case, are added to /proc/iomem. > > $ cat /proc/iomem (on my qemu+edk2 execution) > ... > 4000-5871 : System RAM > 4008-40f1 : Kernel code > 4104-411e9fff : Kernel data > 5440-583f : Crash kernel > 5859-585e : reserved > 5870-5871 : reserved > 5872-58b5 : reserved > 58b6-5be3 : System RAM > 58b61000-58b61fff : reserved > 59a7b118-59a7b667 : reserved > 5be4-5bec : reserved > 5bed-5bed : System RAM > 5bee-5bff : reserved > 5c00-5fff : System RAM > 5ec0-5e
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
Hello Akashi, On 3/6/2018 4:00 AM, AKASHI Takahiro wrote: Tyler, Jeffrey, On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyler Baicar wrote: On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: Tyler, Jeffrey, [Note: This issue takes place in kexec, not kdump. So to be precise, it is not the same phenomenon as what I addressed in [1],[2]: [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557254.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553098.html ] On Thu, Mar 01, 2018 at 12:56:38PM -0500, Tyler Baicar wrote: 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 0x0a4c1c18 to 0x0a4c1cf0. But then by dumping /proc/iomem this region appears as part of System RAM rather than being reserved: 08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System RAM That overlaps the ESRT reservation - [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to 0x0b7087f0 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: Many thanks. According to the data, ESRT was overwritten by initrd, not the kernel image. It doesn't matter to you though :) The solution would be, as Ard suggested, that more information be added to /proc/iomem. I'm going to fix the issue as quickly as possible. Great, thank you!! Please add us to the fix and we will gladly test it out. I have created a workaround patch, attached below, as a kind of PoC. Can you give it a go, please? You need another patch for kexec-tools, too. See https:/git.linaro.org/people/takahiro.akashi/kexecl-tools.git arm64/resv_mem With this patch, extra entries for firmware-reserved memory resources, which means any regions that are already reserved before arm64_memblock_init(), or specifically efi/acpi tables in this case, are added to /proc/iomem. $ cat /proc/iomem (on my qemu+edk2 execution) ... 4000-5871 : System RAM 4008-40f1 : Kernel code 4104-411e9fff : Kernel data 5440-583f : Crash kernel 5859-585e : reserved 5870-5871 : reserved 5872-58b5 : reserved 58b6-5be3 : System RAM 58b61000-58b61fff : reserved 59a7b118-59a7b667 : reserved 5be4-5bec : reserved 5bed-5bed : System RAM 5bee-5bff : reserved 5c00-5fff : System RAM 5ec0-5edf : reserved 80-ff : PCI Bus :00 80-803fff : :00:01.0 80-803fff : virtio-pci-modern While all the entries are currently marked as just "reserved," we'd better give them more specific names for general/extensive use. (Then it will require modifying respective fw/drivers.) Kexec-tools will allocate spaces for kernel, initrd and dtb so that they will not be overlapped with "reserved" memory. As I haven't run extensive tests, please let me know if you find any problems. Thank you! I've run the test with both the kernel patch and the kexec patch and can see that this fixes the issue. I see my ESRT memory space marked as reserved: [ 0.
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
Tyler, Jeffrey, On Fri, Mar 02, 2018 at 08:27:11AM -0500, Tyler Baicar wrote: > On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: > >Tyler, Jeffrey, > > > >[Note: This issue takes place in kexec, not kdump. So to be precise, > >it is not the same phenomenon as what I addressed in [1],[2]: > > [1] > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557254.html > > [2] > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553098.html > >] > > > >On Thu, Mar 01, 2018 at 12:56:38PM -0500, Tyler Baicar wrote: > >>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 0x0a4c1c18 to > >>0x0a4c1cf0. > >> > >>But then by dumping /proc/iomem this region appears as part of System > >>RAM > >>rather than being reserved: > >> > >>08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System > RAM > > That overlaps the ESRT reservation - > [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to > 0x0b7087f0 > > >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: > >Many thanks. > >According to the data, ESRT was overwritten by initrd, not the kernel image. > >It doesn't matter to you though :) > > > >The solution would be, as Ard suggested, that more information be > >added to /proc/iomem. > >I'm going to fix the issue as quickly as possible. > Great, thank you!! Please add us to the fix and we will gladly test it out. I have created a workaround patch, attached below, as a kind of PoC. Can you give it a go, please? You need another patch for kexec-tools, too. See https:/git.linaro.org/people/takahiro.akashi/kexecl-tools.git arm64/resv_mem With this patch, extra entries for firmware-reserved memory resources, which means any regions that are already reserved before arm64_memblock_init(), or specifically efi/acpi tables in this case, are added to /proc/iomem. $ cat /proc/iomem (on my qemu+edk2 execution) ... 4000-5871 : System RAM 4008-40f1 : Kernel code 4104-411e9fff : Kernel data 5440-583f : Crash kernel 5859-585e : reserved 5870-5871 : reserved 5872-58b5 : reserved 58b6-5be3 : System RAM 58b61000-58b61fff : reserved 59a7b118-59a7b667 : reserved 5be4-5bec : reserved 5bed-5bed : System RAM 5bee-5bff : reserved 5c00-5fff : System RAM 5ec0-5edf : reserved 80-ff : PCI Bus :00 80-803fff : :00:01.0 80-803fff : virtio-pci-modern While all the entries are currently marked as just "reserved," we'd better give them more specific names for general/extens
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
On 3/2/2018 12:53 AM, AKASHI Takahiro wrote: Tyler, Jeffrey, [Note: This issue takes place in kexec, not kdump. So to be precise, it is not the same phenomenon as what I addressed in [1],[2]: [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557254.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/553098.html ] On Thu, Mar 01, 2018 at 12:56:38PM -0500, Tyler Baicar wrote: 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 0x0a4c1c18 to 0x0a4c1cf0. But then by dumping /proc/iomem this region appears as part of System RAM rather than being reserved: 08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System RAM That overlaps the ESRT reservation - [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to 0x0b7087f0 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: Many thanks. According to the data, ESRT was overwritten by initrd, not the kernel image. It doesn't matter to you though :) The solution would be, as Ard suggested, that more information be added to /proc/iomem. I'm going to fix the issue as quickly as possible. Great, thank you!! Please add us to the fix and we will gladly test it out. 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.
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
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 0x0a4c1c18 to 0x0a4c1cf0. > >> > >>But then by dumping /proc/iomem this region appears as part of System RAM > >>rather than being reserved: > >> > >>08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System RAM > > That overlaps the ESRT reservation - > [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to > 0x0b7087f0 > > > > >Are you using initrd with kexec? > > Yes To make the things clear, can you show me, if possible, the followings: * dmesg * /proc/iomem * the output from "kexec -d", particularly the last part like kexec_load: entry = 0x411d7660 flags = 0xb7 nr_segments = 3 segment[0].buf = 0x86613010 segment[0].bufsz = 0x10e9b48 segment[0].mem = 0x4008 segment[0].memsz = 0x1156000 segment[1].buf = 0x86211010 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 Thanks, -Takahiro AKASHI > > > >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 majord...@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.
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 0x0a4c1c18 to 0x0a4c1cf0. But then by dumping /proc/iomem this region appears as part of System RAM rather than being reserved: 08f1-0dee : 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 0x8f8 (or 0x908?, 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: 09611000 - 0e5f : System RAM That overlaps the ESRT reservation - [ 0.00] esrt: Reserving ESRT space from 0x0b708718 to 0x0b7087f0 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 majord...@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.
Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
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 0x0a4c1c18 to 0x0a4c1cf0. > > But then by dumping /proc/iomem this region appears as part of System RAM > rather than being reserved: > > 08f1-0dee : 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? 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 0x8f8 (or 0x908?, not sure) in your case. It may or may not be overlapped with ESRT. (Try "-d" option when executing kexec command for confirmation.) Are you using initrd with kexec? 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. >
[PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
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 0x0a4c1c18 to 0x0a4c1cf0. But then by dumping /proc/iomem this region appears as part of System RAM rather than being reserved: 08f1-0dee : 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(). 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.
