[PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
Simon Glass
sjg at chromium.org
Fri Jun 21 21:38:07 CEST 2024
Hi Tom,
On Fri, 21 Jun 2024 at 13:19, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Jun 21, 2024 at 11:55:42AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 21 Jun 2024 at 10:05, Tom Rini <trini at konsulko.com> wrote:
> [snip]
> > > Yes, I very much do not like guessing about 3 numbers instead of
> > > guessing about 1 number and using the standard mechanism we already
> > > have. Please use BOARD_SIZE_LIMIT as this is the standard mechanism to
> > > enforce size limits on U-Boot itself.
> >
> > If it were that easy I would have sent a patch :-)
> >
> > Here is the map for this board:
> >
> > ImagePos Offset Size Name
> > 00000000 00000000 00800000 rom
> > ff800000 ff800000 00001000 intel-descriptor
> > ff801000 ff801000 001ff000 intel-me
> > ffef0000 ffef0000 000999f0 u-boot-with-ucode-ptr
> > fff899f0 fff899f0 00005554 u-boot-dtb-with-ucode
> > fff8ef50 fff8ef50 00000000 u-boot-ucode
> > fff8ef50 fff8ef50 00000571 fdtmap
> > fff90000 fff90000 00010000 intel-vga
> > fffa0000 fffa0000 0002fc94 intel-mrc
> > fffcfc94 fffcfc94 00000000 private-files
> > fffff800 fffff800 00000070 x86-start16
> > fffffff0 fffffff0 00000005 x86-reset16
> > fffffff8 fffffff8 00000008 image-header
> >
> > What limit should I set on what?
>
> Is this a trick question?
> $ printf %d\\n $(( 0xfff90000 - 0xffef0000))
> 655360
>
> Of course since we're less than that today, you can reduce it by
> whatever other magic numbers I'm not seeing but are part of your assumed
> sizes.
That limit is on u-boot-nodtb.bin. Even with a size (for that file) of
634816 it doesn't fit. I need to calculate a size based on the size of
the dtb and the microcode...which of course can change.
>
> > - the U-Boot is the thing you are wanting to limit
> > - the dtb has microcode added
> > - the ucode is empty in this case
> > - the fdtmap is variable in size
> >
> > So this all seems a bit backwards. The actual limit is that
> > (u-boot-with-ucode-ptr + u-boot-dtb-with-ucode + u-boot-ucode +
> > fdtmap) fits in the space available. Note that some boards don't have
> > intel-vga or intel-mrc.
> >
> > With the other patch I sent I can have a sensible limit for all x86 boards.
Did you miss the comments above?
>
> And you can set the same sensible limit with the existing mechanism with
> the bonus of it not making x86 different from the rest?
I understand that it is possible to set a limit for u-boot-nodtb.bin
but that is not accurate nor sufficient in the presence of blobs. The
solution belongs in Binman.
Regards,
Simon
More information about the U-Boot
mailing list