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 <tr...@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
signature.asc
Description: PGP signature
