Hi Simon,
On Thu, 15 Aug 2024 at 23:35, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Wed, 14 Aug 2024 at 07:07, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon
On Wed, 14 Aug 2024 at 15:40, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Wed, 14 Aug 2024 at 05:03, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 1 Aug 2024 at 20:36, Simon Glass sjg@chromium.org wrote:
Currently this calls efi_alloc() which reserves a page for each allocation and this can overwrite memory that will be used for reading images.
Switch the code to use malloc(), as with other parts of EFI, such as efi_add_protocol().
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
What about https://lore.kernel.org/u-boot/CAFLszTjLAKaYK_jLXJ7Z571L-QMtoiqE-oxHCRs186dZ... ?
Yes, I reordered the patches in this series.
You don't need to reorder them. As Heinrich already pointed out some of these functions are used in EFI protocols. e.g duplicate_device_path() requires the memory to be allocated by EFI memory services, you can't just replace it with malloc.
The pointers returned can be freed with EFI services. I don't see any problem here. All the tests pass and all the spec rules are followed, so far as I can tell.
Where exactly does that happen in the current patch?
efi_alloc() calls efi_allocate_pool() and when we need to free the device path we are calling efi_free_pool()
/Ilias
Bear in mind that I am changing the *implementation* of some memory routines, but not in a way that is visible to clients.
I will send a v2 with things split up a bit more, so long as we remember that the EFI patches cannot be applied until the non-EFI patches land.
Regards, Simon