[PATCH 5/6] efi: Use malloc() for the EFI pool

Simon Glass sjg at chromium.org
Thu Aug 1 19:43:58 CEST 2024


Hi Ilias,

On Thu, 1 Aug 2024 at 10:22, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> hi Simon,
>
> On Thu, 1 Aug 2024 at 19:14, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Thu, 1 Aug 2024 at 04:14, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hi Tom
> > >
> > > On Wed, 31 Jul 2024 at 20:17, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Wed, Jul 31, 2024 at 08:39:23AM -0600, Simon Glass wrote:
> > > >
> > > > [snip]
> > > > > > > > so that
> > > > > > > > step three can be seeing what tweaks may be needed in where things
> > > > > > > > allocate memory.
> > > > > > >
> > > > > > > So my series is step 3?
> > > > > >
> > > > > > Or at least understanding what the problems may still be, yes.
> > > > >
> > > > > In that case I would like to clean up EFI's memory management before
> > > > > doing step 2, since I believe many of the problems will just go away
> > > > > if we can get that right.
> > > >
> > > > Well, I think that's where some of the big points of contention are,
> > > > yes. You say "fix" and Ilias and Heinrich say "but the spec".
> > >
> > > Using malloc on efi_allocate_pool() would be ok spec-wise. Simon's
> > > current patch is ignoring the efi memory type metadata we have to
> > > preserve. On top of that using malloc for a *single* memory type, just
> > > kicks the can down the road until an EFI app chooses a different type
> > > and we are back to the same problem.
> > >
> > > It's fine to teach efi_allocate_pool to use malloc with 2 conditions
> > > - memory types are preserved for all allocations
> > > - malloc area is big enough
> >
> > OK thanks I will take a look.
> >
> > I see the EFI code eventually dealing with memory in two distinct phases:
> > - before the app runs: we try to keep memory usage to within areas people expect
> > - once the app runs: t doesn't matter anymore
>
> You need to define 'the app' a bit better.
> An app for example may load, use efi_allocate_pool to inject some
> runtime memory data which the OS expects and exit. The you would load
> you OS (which is really another EFI app). In general I wouldn't make
> any assumptions on what EFI apps will do wrt to memory

My intention is not to make assumptions about what EFI apps will do*.

But I do see value in separating the setup done by U-Boot from the
operation of the app. My point is that once the app starts, we don't
care what memory the app uses, so long as it allocates things
properly. If the app exits back to U-Boot and then U-Boot runs another
app, I would say we are in 'EFI land' as soon as the first app runs,
so further EFI apps don't really change that. EFI apps are allowed to
allocate memory as they wish...they can even request a particular
memory address!

Regards,
Simon

> > > > Perhaps once step one is done it will be easier to find a way to address
> > > > your concerns without also breaking "the spec".


* After all, that is my primary criticism of EFI as a whole.


More information about the U-Boot mailing list