Proposal: U-Boot memory management

Heinrich Schuchardt xypron.glpk at gmx.de
Tue Dec 19 00:29:19 CET 2023



Am 19. Dezember 2023 00:16:40 MEZ schrieb Tom Rini <trini at konsulko.com>:
>On Tue, Dec 19, 2023 at 12:08:31AM +0100, Heinrich Schuchardt wrote:
>> 
>> 
>> Am 18. Dezember 2023 23:41:08 MEZ schrieb Tom Rini <trini at konsulko.com>:
>> >On Mon, Dec 18, 2023 at 11:34:16PM +0100, Heinrich Schuchardt wrote:
>> >
>> >[snip]
>> >> Or take:
>> >> 
>> >> load host 0:1 $c kernel.efi
>> >> load host 0:1 $d initrd.img
>> >> 
>> >> How could we ensure that initrd.img is not overwriting a part of kernel.efi without memory allocation?
>> >
>> >Today, invalid checksum as part of some part of the kernel fails. But
>> >how do we do this tomorrow, are you suggesting that "load" perform
>> >malloc() in some predefined size? If $c is below $d and $c + kernel.efi
>> >is now above $d we can throw an error before trying to load, yes. But
>> >what about:
>> >load host 0:1 $d initrd.img
>> >load host 0:1 $c kernel.efi
>> >
>> >In that case (which is only marginally contrived, the more real case is
>> >loading device tree in to unexpectedly large ramdisk because someone
>> >didn't understand the general advice on why device tree is lower than
>> >ramdisk address) I'm fine with an error that amounts to "you just
>> >corrupted another allocation" and then "fail, reset the board" or so.
>> >
>> 
>> Our current malloc library cannot manage the complete memory. We need a library like lmb which should also cover the memory management that we currently have in lib/efi/efi_memory.c. This must include a memory type attribute for usage in the GetMemoryMap() service. A management on page level seems sufficient.
>> 
>> The load command should permanently allocate memory in that lmb+ library.
>> 
>> We need an unload command to free the memory if we want to reuse the memory or we might let the load comand free the memory if exactly the same start address is reused.
>
>Our current way of loading things in to memory does not handle the case
>I described, yes. How would what you're proposing handle it?

If the load command has to allocate memory for the image and that allocation is kept, any attempt to allocate overlapping memory would fail.

Furthermore the EFI sub-system would be aware of such memory allocations and respect them. This would of course also hold true for allocations for SMBIOS or ACPI tables.

Best regards

Heinrich


More information about the U-Boot mailing list