[RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable

[Simon Glass]

Hi Tom,

On Wed, 12 Jun 2024 at 15:40, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 12 Jun 2024 at 11:22, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote:
> > >
> > > [snip]
> > > > Also IMO there is only really one LMB list today. We create it at the
> > > > start of bootm and then it is done when we boot. The file-loading
> > > > stuff is what makes all this confusing...and with bootstd that is
> > > > under control as well.
> > > >
> > > > At lot of this effort seems to be about dealing with random scripts
> > > > which load things. We want to make sure we complain if something
> > > > overlaps. But we should be making the bootstd case work nicely and
> > > > doing things within that framework. Also EFI sort-of has its own
> > > > thing, which it is very-much in control of.
> > > >
> > > > Overall I think this is a bit more subtle that just combining allocators.
> > >
> > > I think this gets to the main misunderstanding. The problem isn't
> > > handling bootstd, or EFI boot, or even assorted scripts. Those are all
> > > cases where things are otherwise (sufficiently) well-defined. The
> > > problem is "security" and that a "carefully crafted payload" could do
> > > something malicious. That's why we have to do all of this stuff sooner
> > > rather than later in our boot process.
> >
> > That's the first I have heard of this, actually, but a bit more detail
> > would help. How does the payload get loaded? I'm just not sure about
> > the overall goals. It seems that everyone else is already familiar -
> > can someone please take the time to point me to the details?
>
> Well, the short version I believe of the first CVE we got (and so
> started abusing LMB) was along the lines of "load an image near where
> the U-Boot stack is, smash things for fun and exploits".

OK. I am surprised that LMB does not catch that. It is supposed to add
the stack and various other things right at the start before loading
any file. So even if it clears the LMB each time, it should not be
able to do that. Having said this, the code may be buggy as I don't
think we have tests for U-Boot's overall functional behaviour in these
situations.

Regards,
Simon