[PATCH v2 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL

Tom Rini trini at konsulko.com
Fri Jun 21 21:19:15 CEST 2024


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.

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

And you can set the same sensible limit with the existing mechanism with
the bonus of it not making x86 different from the rest?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240621/b7cfd44f/attachment.sig>


More information about the U-Boot mailing list