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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

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@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".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]