On Sat, Mar 21, 2015 at 09:39:57PM -0400, Stefan Berger wrote:
On 03/20/2015 08:59 PM, Kevin O'Connor wrote:
On Fri, Mar 20, 2015 at 02:00:36PM -0400, Stefan Berger wrote:
From: Stefan Berger stefann@linux.vnet.ibm.com
This patch adds an implementation of a TPM TIS driver for the TPM TIS emulation supported by QEMU. The driver is broken up into several small functions that have to be called in proper sequence. The driver is cleanly separated from the rest of the code through an interface holding pointers to the driver's functions. A client using this driver first probes whether the TPM TIS interface is available (probe function) and then invokes the interface function to initialze the interface and send requests and receive responses.
[...]
+struct tpm_driver tpm_drivers[TPM_NUM_DRIVERS] = {
- [TIS_DRIVER_IDX] =
{.timeouts = NULL,.durations = NULL,.set_timeouts = set_timeouts,.probe = tis_probe,.init = tis_init,.activate = tis_activate,.ready = tis_ready,.senddata = tis_senddata,.readresp = tis_readresp,.waitdatavalid = tis_waitdatavalid,.waitrespready = tis_waitrespready,.sha1threshold = 100 * 1024,},+};
Can any of the above functions be called after SeaBIOS finishes its POST phase? If so, I think the function pointers may confuse the build's detection of runtime vs init only code.
These functions can be called until the very end, even when the bootloaded (trusted grub) calls the BIOS API. I haven't seen any crashes that presumably would happen due to the memory of the table getting reused. How can we make sure that this table stays alive during runtime?
If the table itself is referenced by "runtime code" then it should be okay. You can check to see that the table and its associated functions are not between code32init_start and code32init_end (by looking at out/romlayout32flat.lds or an objdump of the rom).
If, however, a pointer to the table (or one of the funcs) is copied to some struct during init and the only "runtime" references are via that copied pointer, then that could confuse the build check.
-Kevin