[SeaBIOS] [PATCH 0/7] Some TPM code reorganization

[Kevin O'Connor]

On Sun, Nov 22, 2015 at 11:11:36PM -0500, Stefan Berger wrote:
> On 11/22/2015 08:26 PM, Kevin O'Connor wrote:
> >I will hold off on further changes until you can merge any features
> >you have pending.
> 
> It's mostly the menu that I would want to have merged next. All patches
> after that are not that important and I'll only resurrect them once the
> changes here settle.

Okay.  I forget why the menu code didn't get added - can you resend
it?

> I looked over and tried your 2nd series of 8 patches and the tests I did all
> had the same results as without these patches applied. So from my point of
> view, they can be applied.
> I leave it up to you regarding 4/8 and the fixed-size buffer on the stack.
> If we ever have a bigger message to pass then we can adjust the buffer
> following the warning the code is emitting, otherwise if we pass the event
> and its size around we won't have to do that. If stack usage is not an issue
> I think your changes in probably the right direction.

SeaBIOS (by default) uses its own 2K stack for "runtime" usage (the
16bit bios calls), and it has either a 4K or 16K stack during the POST
phase.

If performance was a concern, tpm_extend_acpi_log() could be split
into two parts (eg, tpm_log_get_space() and tpm_log_reserve_space() )
and the calling code could directly memcpy everything to its final
location in the acpi log.  However, it seems like just undoing my
patch 4 makes the most sense.  I'll pull that patch out and repost
tonight.

> All the arrays at the beginning of the file are basically the bodies of TPM
> requests. We could extend those arrays by prefixing them with their headers
> and won't have to build the header in the transmit function anymore. Some
> messages will still need to be built, like TPM_Extend, but those can be
> hard-coded. Is that a change we would want?

It's possible to do that for build_and_send_cmd().  The biggest
command (in the current code) is 12 bytes though, so it seems like it
is just simpler to copy it.

> I am also trying to add similar code to SLOF, which is under BSD. I hope
> that you agree that I can make similar transformations that you did to the
> pending SLOF patches as well.

Yes, that's fine.

-Kevin