On Tue, Dec 19, 2023 at 12:08:31AM +0100, Heinrich Schuchardt wrote: > > > Am 18. Dezember 2023 23:41:08 MEZ schrieb Tom Rini <[email protected]>: > >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? -- Tom
signature.asc
Description: PGP signature
