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

[Tom Rini <trini@konsulko.com>]

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

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

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