Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36027 )
Change subject: [WIP]nb/intel/nehalem: Add a VBOOT TPM init workaround ......................................................................
Patch Set 6:
Patch Set 5:
Setting MOCK_SECDATA is currently not an option with TPM enabled as even with MOCK_SECDATA a different path will be taken on TPM init failure. A new Kconfig option NO_TPM_IN_VBOOT could be added to work around it maybe?
Yes, maybe we should do that. In CB:34510 we just assumed that everyone who has TPM1 || TPM2 enabled in Kconfig would want the TPM initialization to happen in vboot. But maybe we should insert a separate VBOOT_USE_TPM option in-between to decouple that and allow platforms to override if necessary. (I assume just running completely without TPM support is not an option for your use case?)
This might look like the most sane approach for now.
This is just a way to skip the init the second time VBOOT runs after the soft reset as the init command returns failure if already initialized. Another way to work around this issue is to only run verstage after the reset and therefore running the RO romstage (partially) before reset.
This could be reasonable but do you have a clean way to do that? I don't think there's a way for platforms to override the vboot_locator that decides when to run vboot, and I don't think we'd want to add that either.
Patrick also stated a somewhat similar use case where TXT already initializes the TPM before VBOOT. How unreasonable is it to provide a hook in the TPM init to deal tlcl_startup() failure if one knows the TPM has already been initialized? This is quite similar to what is done on the S3 path in tpm_setup_s3_helper(). This could be unified to deal with other situations where the TPM is known to be initialized prior to VBOOT?
Another really hacky option might be to make sure vboot_platform_is_resuming() returns true for the second boot, and pretend it's an S3 resume. That's not any better than this patch, but at least it would contain those hacks within the platform.
Your last suggestion seems to work but if one request recovery version checking should be disabled but this is not the case anymore, so this is actually worse than with the quirk handling.