RE: [PATCH] efi_loader : Suppress error print message
[AMD Official Use Only - General] Hi Heinrich, > -Original Message- > From: Heinrich Schuchardt > Sent: Monday, January 29, 2024 4:09 AM > To: Bhumkar, Tejas Arvind > Cc: Ilias Apalodimas ; U-Boot Mailing List b...@lists.denx.de>; Tom Rini > Subject: Re: [PATCH] efi_loader : Suppress error print message > > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > On 1/28/24 18:38, Bhumkar, Tejas Arvind wrote: > > [AMD Official Use Only - General] > > > > Hi Heinrich, > > > >> -Original Message- > >> From: Heinrich Schuchardt > >> Sent: Sunday, January 28, 2024 2:51 PM > >> To: Bhumkar, Tejas Arvind > >> Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; > >> Simek, Michal ; Abbarapu, Venkatesh > >> ; g...@xilinx.com; Ilias Apalodimas > >> > >> Subject: Re: [PATCH] efi_loader : Suppress error print message > >> > >> Caution: This message originated from an External Source. Use proper > >> caution when opening attachments, clicking links, or responding. > >> > >> > >> On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote: > >>> [AMD Official Use Only - General] > >>> > >>> Hi Heinrich, > >>> > >>>> -Original Message- > >>>> From: Heinrich Schuchardt > >>>> Sent: Wednesday, January 24, 2024 2:09 AM > >>>> To: Bhumkar, Tejas Arvind > >>>> Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; > >>>> Simek, Michal ; Abbarapu, Venkatesh > >>>> ; g...@xilinx.com; Ilias Apalodimas > >>>> > >>>> Subject: Re: [PATCH] efi_loader : Suppress error print message > >>>> > >>>> Caution: This message originated from an External Source. Use > >>>> proper caution when opening attachments, clicking links, or responding. > >>>> > >>>> > >>>> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: > >>>>> [AMD Official Use Only - General] > >>>>> > >>>>> Hi Ilias & Heinrich, > >>>>> > >>>>>> -Original Message- > >>>>>> From: Heinrich Schuchardt > >>>>>> Sent: Tuesday, January 23, 2024 3:30 PM > >>>>>> To: Ilias Apalodimas ; Bhumkar, > >>>>>> Tejas Arvind > >>>>>> Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; > >>>>>> s...@chromium.org; Simek, Michal ; Abbarapu, > >>>>>> Venkatesh ; g...@xilinx.com > >>>>>> Subject: Re: [PATCH] efi_loader : Suppress error print message > >>>>>> > >>>>>> Caution: This message originated from an External Source. Use > >>>>>> proper caution when opening attachments, clicking links, or responding. > >>>>>> > >>>>>> > >>>>>> On 1/23/24 09:33, Ilias Apalodimas wrote: > >>>>>>> Hi Tejas, > >>>>>>> > >>>>>>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Currently, on certain Xilinx platforms, an issue has been > >>>>>>>> identified, manifesting as follows: > >>>>>> > >>>>>> Hello Tejas, > >>>>>> > >>>>>> thank you for bringing forward this issue. > >>>>>> > >>>>>> Which defconfig are you relating to? > >>>>> > >>>>> [Tejas]: > >>>>> Checking with xilinx_zynqmp_virt_defconfig > >>>>> > >>>>>> > >>>>>>>> > >>>>>>>> Starting kernel ... > >>>>>>>> > >>>>>>>> efi_free_pool: illegal free 0x77830040 > >>>>>>>> efi_free_pool: illegal free 0x7782d040 > >>>>>>>> efi_free_pool: illegal free 0x7782c040 > >>>>>>>> > >>>>>>>> The issue arises when the ramdisk image is relocated, placing > >>>>>>>> it within the previously allocated EFI memory region( as EFI is > >>>>>>>> established quit
Re: [PATCH] efi_loader : Suppress error print message
On 1/28/24 10:20, Heinrich Schuchardt wrote: On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Wednesday, January 24, 2024 2:09 AM To: Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com; Ilias Apalodimas Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Ilias & Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Tuesday, January 23, 2024 3:30 PM To: Ilias Apalodimas ; Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 09:33, Ilias Apalodimas wrote: Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: Currently, on certain Xilinx platforms, an issue has been identified, manifesting as follows: Hello Tejas, thank you for bringing forward this issue. Which defconfig are you relating to? [Tejas]: Checking with xilinx_zynqmp_virt_defconfig Starting kernel ... efi_free_pool: illegal free 0x77830040 efi_free_pool: illegal free 0x7782d040 efi_free_pool: illegal free 0x7782c040 The issue arises when the ramdisk image is relocated, placing it within the previously allocated EFI memory region( as EFI is established quite early in U-Boot). Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI memory map") was meant to avoid such a situation. [Tejas] : I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora. com/ Could you, please, try to reproduce your issues with origin/master as of today and provide the full boot log. Please, also provide the output of the bdinfo and the printenv command as well as the sizes of the kernel and the RAM disk. [Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error. Thank You, Tejas. Where can I find these logs? They were attached but you can see them for example here. https://lore.kernel.org/all/bl3pr12mb645027991850d2c0887fa80dd8...@bl3pr12mb6450.namprd12.prod.outlook.com/ Thanks, Michal
Re: [PATCH] efi_loader : Suppress error print message
On 1/28/24 18:38, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Sunday, January 28, 2024 2:51 PM To: Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com; Ilias Apalodimas Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Wednesday, January 24, 2024 2:09 AM To: Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com; Ilias Apalodimas Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Ilias & Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Tuesday, January 23, 2024 3:30 PM To: Ilias Apalodimas ; Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 09:33, Ilias Apalodimas wrote: Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: Currently, on certain Xilinx platforms, an issue has been identified, manifesting as follows: Hello Tejas, thank you for bringing forward this issue. Which defconfig are you relating to? [Tejas]: Checking with xilinx_zynqmp_virt_defconfig Starting kernel ... efi_free_pool: illegal free 0x77830040 efi_free_pool: illegal free 0x7782d040 efi_free_pool: illegal free 0x7782c040 The issue arises when the ramdisk image is relocated, placing it within the previously allocated EFI memory region( as EFI is established quite early in U-Boot). Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI memory map") was meant to avoid such a situation. [Tejas] : I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora. com/ Could you, please, try to reproduce your issues with origin/master as of today and provide the full boot log. Please, also provide the output of the bdinfo and the printenv command as well as the sizes of the kernel and the RAM disk. [Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error. Thank You, Tejas. Where can I find these logs? [Tejas ] : I've sent the attachment in a previous email. I'm not sure why you didn't receive it. I've attached it again now. Please confirm if you still haven't received it. Thank You, Tejas. If I understand your FDT_memory_region_failed.log correctly: Except for some added debug messages this log matches booting with an unmodified upstream U-Boot as of Jan 22nd. Your memory is split into two regions: 0x0 - 0x7ff and 0x8 - 0x87ff. Your device-tree has a reserved region 0x7ff0-0x7fff. U-Boot relocates itself into the lower memory block due to current design. efi_lmb_reserve() marks memory up to 0x7fff and 0x8-0x87fff as reserved. boot_fdt_reserve_region() writes an error when it tries to reserve the overlapping region 0x7ff0-0x7fff because LMB recognizes this region is already reserved. This should not interfere with booting as boot_fdt_reserve_region() does not have a return value but is not very clean and should be fixed. Best regards Heinrich I don't mind suppressing the print for some time, but out of curiosity, how is the ramdisk relocated? LMB should be aware of the EFI regions by then, so I assume the relocation code doesn't check those? [Tejas] : I observe that the relocation of the RAM disk is taking place in the line below. https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491 Yes, the relocated code specifically examines the LMB region and does not
Re: [PATCH] efi_loader : Suppress error print message
On 1/28/24 06:20, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Wednesday, January 24, 2024 2:09 AM To: Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com; Ilias Apalodimas Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Ilias & Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Tuesday, January 23, 2024 3:30 PM To: Ilias Apalodimas ; Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 09:33, Ilias Apalodimas wrote: Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: Currently, on certain Xilinx platforms, an issue has been identified, manifesting as follows: Hello Tejas, thank you for bringing forward this issue. Which defconfig are you relating to? [Tejas]: Checking with xilinx_zynqmp_virt_defconfig Starting kernel ... efi_free_pool: illegal free 0x77830040 efi_free_pool: illegal free 0x7782d040 efi_free_pool: illegal free 0x7782c040 The issue arises when the ramdisk image is relocated, placing it within the previously allocated EFI memory region( as EFI is established quite early in U-Boot). Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI memory map") was meant to avoid such a situation. [Tejas] : I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora. com/ Could you, please, try to reproduce your issues with origin/master as of today and provide the full boot log. Please, also provide the output of the bdinfo and the printenv command as well as the sizes of the kernel and the RAM disk. [Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error. Thank You, Tejas. Where can I find these logs? Best regards Heinrich Best regards Heinrich I don't mind suppressing the print for some time, but out of curiosity, how is the ramdisk relocated? LMB should be aware of the EFI regions by then, so I assume the relocation code doesn't check those? [Tejas] : I observe that the relocation of the RAM disk is taking place in the line below. https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491 Yes, the relocated code specifically examines the LMB region and does not consider the EFI region. The indicated situation is serious. If the EFI sub-system is using the same memory area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing the messages is by no means adequate to solve the problem. [Tejas] : The challenge arises when relocating the ramdisk image, inserting it into the previously assigned EFI memory region, established early in U-Boot. Consequently, when attempting to release memory in the EFI region during the handover process to the kernel in the efi_free_pool function, we first verify if the memory was allocated by efi_allocate_pool(). The issue originates from a checksum mismatch because, during the ramdisk relocation, we overwrite memory allocated by EFI. This leads to the appearance of the error message: efi_free_pool: illegal free 0x77830040. Crucially, there is no corruption of the ramdisk seen since we do not actually releasing memory due to the checksum mismatch. In our testing, this issue was observed only when the ramdisk size exceeded approximately 24 MB. Best regards Heinrich Thanks /Ilias Consequently, when attempting to release memory in the EFI memory region during the handover process to the kernel,we encounter memory violations. Highlighting that EFI remains active primarily during the booting of an EFI application, and the lmb persists while configuring images for the boot process. Since we aren't utilizing the EFI memory region during the boot process, there is no adverse impact even in the
RE: [PATCH] efi_loader : Suppress error print message
[AMD Official Use Only - General] Hi Heinrich, > -Original Message- > From: Heinrich Schuchardt > Sent: Wednesday, January 24, 2024 2:09 AM > To: Bhumkar, Tejas Arvind > Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal > ; Abbarapu, Venkatesh > ; g...@xilinx.com; Ilias Apalodimas > > Subject: Re: [PATCH] efi_loader : Suppress error print message > > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: > > [AMD Official Use Only - General] > > > > Hi Ilias & Heinrich, > > > >> -Original Message- > >> From: Heinrich Schuchardt > >> Sent: Tuesday, January 23, 2024 3:30 PM > >> To: Ilias Apalodimas ; Bhumkar, Tejas > >> Arvind > >> Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; > >> s...@chromium.org; Simek, Michal ; Abbarapu, > >> Venkatesh ; g...@xilinx.com > >> Subject: Re: [PATCH] efi_loader : Suppress error print message > >> > >> Caution: This message originated from an External Source. Use proper > >> caution when opening attachments, clicking links, or responding. > >> > >> > >> On 1/23/24 09:33, Ilias Apalodimas wrote: > >>> Hi Tejas, > >>> > >>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar > >>> wrote: > >>>> > >>>> Currently, on certain Xilinx platforms, an issue has been > >>>> identified, manifesting as follows: > >> > >> Hello Tejas, > >> > >> thank you for bringing forward this issue. > >> > >> Which defconfig are you relating to? > > > > [Tejas]: > > Checking with xilinx_zynqmp_virt_defconfig > > > >> > >>>> > >>>> Starting kernel ... > >>>> > >>>> efi_free_pool: illegal free 0x77830040 > >>>> efi_free_pool: illegal free 0x7782d040 > >>>> efi_free_pool: illegal free 0x7782c040 > >>>> > >>>> The issue arises when the ramdisk image is relocated, placing it > >>>> within the previously allocated EFI memory region( as EFI is > >>>> established quite early in U-Boot). > >> > >> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: > >> consider EFI memory map") was meant to avoid such a situation. > > > > [Tejas] : > > I'm verifying against the latest changes in the master branch. The > > introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") > > has resolved the occurrence of the "efi_free_pool: illegal free" > > error. but, it leads to a new error, as detailed in the following > > patch: > > https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora. > > com/ > > Could you, please, try to reproduce your issues with origin/master as of > today and > provide the full boot log. Please, also provide the output of the bdinfo and > the > printenv command as well as the sizes of the kernel and the RAM disk. [Tejas]: I've provided two logs: one obtained from the latest u-boot origin/master, resulting in the "ERROR: reserving fdt memory region failed" error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI memory map"), which leads to the "efi_free_pool: illegal free" error. Thank You, Tejas. > > Best regards > > Heinrich > > > > >> > >>> > >>> I don't mind suppressing the print for some time, but out of > >>> curiosity, how is the ramdisk relocated? LMB should be aware of the > >>> EFI regions by then, so I assume the relocation code doesn't check > >>> those? > > > > > > [Tejas] : I observe that the relocation of the RAM disk is taking place in > > the line > below. > > https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491 > > Yes, the relocated code specifically examines the LMB region and does not > consider the EFI region. > > > >> > >> The indicated situation is serious. If the EFI sub-system is using > >> the same memory area as the ramdisk, this may lead to corruption of > >> the ramdisk. Suppressing the messages is by no means adequate to solve the > problem. > > > > [Tejas] : > > The challenge arises when relocating the ramdisk image, inserting it > > into the previously assigned EFI memory region, establish
Re: [PATCH] efi_loader : Suppress error print message
On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote: [AMD Official Use Only - General] Hi Ilias & Heinrich, -Original Message- From: Heinrich Schuchardt Sent: Tuesday, January 23, 2024 3:30 PM To: Ilias Apalodimas ; Bhumkar, Tejas Arvind Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal ; Abbarapu, Venkatesh ; g...@xilinx.com Subject: Re: [PATCH] efi_loader : Suppress error print message Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On 1/23/24 09:33, Ilias Apalodimas wrote: Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: Currently, on certain Xilinx platforms, an issue has been identified, manifesting as follows: Hello Tejas, thank you for bringing forward this issue. Which defconfig are you relating to? [Tejas]: Checking with xilinx_zynqmp_virt_defconfig Starting kernel ... efi_free_pool: illegal free 0x77830040 efi_free_pool: illegal free 0x7782d040 efi_free_pool: illegal free 0x7782c040 The issue arises when the ramdisk image is relocated, placing it within the previously allocated EFI memory region( as EFI is established quite early in U-Boot). Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI memory map") was meant to avoid such a situation. [Tejas] : I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjo...@collabora.com/ Could you, please, try to reproduce your issues with origin/master as of today and provide the full boot log. Please, also provide the output of the bdinfo and the printenv command as well as the sizes of the kernel and the RAM disk. Best regards Heinrich I don't mind suppressing the print for some time, but out of curiosity, how is the ramdisk relocated? LMB should be aware of the EFI regions by then, so I assume the relocation code doesn't check those? [Tejas] : I observe that the relocation of the RAM disk is taking place in the line below. https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491 Yes, the relocated code specifically examines the LMB region and does not consider the EFI region. The indicated situation is serious. If the EFI sub-system is using the same memory area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing the messages is by no means adequate to solve the problem. [Tejas] : The challenge arises when relocating the ramdisk image, inserting it into the previously assigned EFI memory region, established early in U-Boot. Consequently, when attempting to release memory in the EFI region during the handover process to the kernel in the efi_free_pool function, we first verify if the memory was allocated by efi_allocate_pool(). The issue originates from a checksum mismatch because, during the ramdisk relocation, we overwrite memory allocated by EFI. This leads to the appearance of the error message: efi_free_pool: illegal free 0x77830040. Crucially, there is no corruption of the ramdisk seen since we do not actually releasing memory due to the checksum mismatch. In our testing, this issue was observed only when the ramdisk size exceeded approximately 24 MB. Best regards Heinrich Thanks /Ilias Consequently, when attempting to release memory in the EFI memory region during the handover process to the kernel,we encounter memory violations. Highlighting that EFI remains active primarily during the booting of an EFI application, and the lmb persists while configuring images for the boot process. Since we aren't utilizing the EFI memory region during the boot process, there is no adverse impact even in the event of a violation. Currently, there is an ongoing discussion regarding the handling strategies of three memory allocators: malloc, lmb, and EFI. This discussion is documented in the email chain titled "Proposal: U-Boot memory management." Therefore, it is advisable to suppress the print message during the boot process for now. Signed-off-by: Tejas Bhumkar --- lib/efi_loader/efi_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer) /* Check that this memory was allocated by efi_allocate_pool() */ if (((uintptr_t)alloc & EFI_PAGE_MASK) || alloc->checksum != checksum(alloc)) { - printf("%s: illegal free 0x%p\n", __func__, buffe
RE: [PATCH] efi_loader : Suppress error print message
[AMD Official Use Only - General] Hi Ilias & Heinrich, > -Original Message- > From: Heinrich Schuchardt > Sent: Tuesday, January 23, 2024 3:30 PM > To: Ilias Apalodimas ; Bhumkar, Tejas Arvind > > Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com; > s...@chromium.org; Simek, Michal ; Abbarapu, > Venkatesh ; g...@xilinx.com > Subject: Re: [PATCH] efi_loader : Suppress error print message > > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > On 1/23/24 09:33, Ilias Apalodimas wrote: > > Hi Tejas, > > > > On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar > > wrote: > >> > >> Currently, on certain Xilinx platforms, an issue has been identified, > >> manifesting as follows: > > Hello Tejas, > > thank you for bringing forward this issue. > > Which defconfig are you relating to? [Tejas]: Checking with xilinx_zynqmp_virt_defconfig > > >> > >> Starting kernel ... > >> > >> efi_free_pool: illegal free 0x77830040 > >> efi_free_pool: illegal free 0x7782d040 > >> efi_free_pool: illegal free 0x7782c040 > >> > >> The issue arises when the ramdisk image is relocated, placing it > >> within the previously allocated EFI memory region( as EFI is > >> established quite early in U-Boot). > > Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI > memory map") was meant to avoid such a situation. [Tejas] : I'm verifying against the latest changes in the master branch. The introduction of commit 06d514d77c37 ("lmb: consider EFI memory map") has resolved the occurrence of the "efi_free_pool: illegal free" error. but, it leads to a new error, as detailed in the following patch: https://lore.kernel.org/all/20230212150706.2967007-1-sjo...@collabora.com/ > > > > > I don't mind suppressing the print for some time, but out of > > curiosity, how is the ramdisk relocated? LMB should be aware of the > > EFI regions by then, so I assume the relocation code doesn't check > > those? [Tejas] : I observe that the relocation of the RAM disk is taking place in the line below. https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491 Yes, the relocated code specifically examines the LMB region and does not consider the EFI region. > > The indicated situation is serious. If the EFI sub-system is using the same > memory > area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing > the > messages is by no means adequate to solve the problem. [Tejas] : The challenge arises when relocating the ramdisk image, inserting it into the previously assigned EFI memory region, established early in U-Boot. Consequently, when attempting to release memory in the EFI region during the handover process to the kernel in the efi_free_pool function, we first verify if the memory was allocated by efi_allocate_pool(). The issue originates from a checksum mismatch because, during the ramdisk relocation, we overwrite memory allocated by EFI. This leads to the appearance of the error message: efi_free_pool: illegal free 0x77830040. Crucially, there is no corruption of the ramdisk seen since we do not actually releasing memory due to the checksum mismatch. In our testing, this issue was observed only when the ramdisk size exceeded approximately 24 MB. > > Best regards > > Heinrich > > > > > > Thanks > > /Ilias > > > >> Consequently, when > >> attempting to release memory in the EFI memory region during the > >> handover process to the kernel,we encounter memory violations. > >> > >> Highlighting that EFI remains active primarily during the booting of > >> an EFI application, and the lmb persists while configuring images for > >> the boot process. Since we aren't utilizing the EFI memory region > >> during the boot process, there is no adverse impact even in the event > >> of a violation. > >> > >> Currently, there is an ongoing discussion regarding the handling > >> strategies of three memory allocators: malloc, lmb, and EFI. This > >> discussion is documented in the email chain titled "Proposal: U-Boot > >> memory management." > >> > >> Therefore, it is advisable to suppress the print message during the > >> boot process for now. > >> > >> Signed-off-by: Tejas Bhumkar > >> --- > >> lib/efi_loader/efi_memory.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/li
Re: [PATCH] efi_loader : Suppress error print message
On 1/23/24 09:33, Ilias Apalodimas wrote: Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: Currently, on certain Xilinx platforms, an issue has been identified, manifesting as follows: Hello Tejas, thank you for bringing forward this issue. Which defconfig are you relating to? Starting kernel ... efi_free_pool: illegal free 0x77830040 efi_free_pool: illegal free 0x7782d040 efi_free_pool: illegal free 0x7782c040 The issue arises when the ramdisk image is relocated, placing it within the previously allocated EFI memory region( as EFI is established quite early in U-Boot). Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb: consider EFI memory map") was meant to avoid such a situation. I don't mind suppressing the print for some time, but out of curiosity, how is the ramdisk relocated? LMB should be aware of the EFI regions by then, so I assume the relocation code doesn't check those? The indicated situation is serious. If the EFI sub-system is using the same memory area as the ramdisk, this may lead to corruption of the ramdisk. Suppressing the messages is by no means adequate to solve the problem. Best regards Heinrich Thanks /Ilias Consequently, when attempting to release memory in the EFI memory region during the handover process to the kernel,we encounter memory violations. Highlighting that EFI remains active primarily during the booting of an EFI application, and the lmb persists while configuring images for the boot process. Since we aren't utilizing the EFI memory region during the boot process, there is no adverse impact even in the event of a violation. Currently, there is an ongoing discussion regarding the handling strategies of three memory allocators: malloc, lmb, and EFI. This discussion is documented in the email chain titled "Proposal: U-Boot memory management." Therefore, it is advisable to suppress the print message during the boot process for now. Signed-off-by: Tejas Bhumkar --- lib/efi_loader/efi_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index edfad2d95a..821fe7616e 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer) /* Check that this memory was allocated by efi_allocate_pool() */ if (((uintptr_t)alloc & EFI_PAGE_MASK) || alloc->checksum != checksum(alloc)) { - printf("%s: illegal free 0x%p\n", __func__, buffer); + debug("%s: illegal free 0x%p\n", __func__, buffer); return EFI_INVALID_PARAMETER; } /* Avoid double free */ -- 2.27.0
Re: [PATCH] efi_loader : Suppress error print message
Hi Tejas, On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar wrote: > > Currently, on certain Xilinx platforms, an issue has been > identified, manifesting as follows: > > Starting kernel ... > > efi_free_pool: illegal free 0x77830040 > efi_free_pool: illegal free 0x7782d040 > efi_free_pool: illegal free 0x7782c040 > > The issue arises when the ramdisk image is relocated, placing > it within the previously allocated EFI memory region( as EFI > is established quite early in U-Boot). I don't mind suppressing the print for some time, but out of curiosity, how is the ramdisk relocated? LMB should be aware of the EFI regions by then, so I assume the relocation code doesn't check those? Thanks /Ilias > Consequently, when > attempting to release memory in the EFI memory region during > the handover process to the kernel,we encounter memory violations. > > Highlighting that EFI remains active primarily during the > booting of an EFI application, and the lmb persists while > configuring images for the boot process. Since we aren't > utilizing the EFI memory region during the boot process, > there is no adverse impact even in the event of a violation. > > Currently, there is an ongoing discussion regarding the handling > strategies of three memory allocators: malloc, lmb, and EFI. This > discussion is documented in the email chain > titled "Proposal: U-Boot memory management." > > Therefore, it is advisable to suppress the print message during > the boot process for now. > > Signed-off-by: Tejas Bhumkar > --- > lib/efi_loader/efi_memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c > index edfad2d95a..821fe7616e 100644 > --- a/lib/efi_loader/efi_memory.c > +++ b/lib/efi_loader/efi_memory.c > @@ -713,7 +713,7 @@ efi_status_t efi_free_pool(void *buffer) > /* Check that this memory was allocated by efi_allocate_pool() */ > if (((uintptr_t)alloc & EFI_PAGE_MASK) || > alloc->checksum != checksum(alloc)) { > - printf("%s: illegal free 0x%p\n", __func__, buffer); > + debug("%s: illegal free 0x%p\n", __func__, buffer); > return EFI_INVALID_PARAMETER; > } > /* Avoid double free */ > -- > 2.27.0 >