[iwanicki92]

With a TPM that has only SHA-256 allocated, or SHA-384 as well, every Linux Secure Launch fails. The SKL's event log declares SHA-1 and SHA-256 whatever banks the TPM has. Linux resets on a log whose banks differ from the TPM's, because its extend needs one digest per allocated bank, in the TPM's order.

The last commit asks the TPM for its PCR allocation with TPM2_GetCapability and declares those banks, in that order. Banks the SKL cannot hash get a placeholder digest (01 followed by zeros), as Linux and Xen log for such banks, and the SKL extends the same placeholder there for its own records. If the query fails, the log falls back to SHA-1 and SHA-256.

The commits before it are what the query needs:

1. tis_recv() stored the last byte of every response in the first byte of the body. This commit is taken from patch 0012 in zarhus/meta-trenchboot#58 with its message reworded, because the bank query depends on it.
2. tis_recv() waited one TIMEOUT_D (30 ms on TPM 2.0) for the response. In CI, a software TPM on a busy runner once answered the bank query later than that. The SKL then fell back to SHA-1 and SHA-256 on a TPM with only SHA-256, and the Linux launch failed. A stalled swtpm reproduces it. tis_recv() now polls for up to 2 s, as long as Linux allows for slow commands.
3. convert_digest_list() counted an SM3-256 digest as 20 bytes, so such an extend was built short.
4. The bank code grows the 64-bit DEBUG build until bootloader_data leaves GRUB less than the 4 KiB it needs for the SLRT, and GRUB then rejects the SKL. The linker script puts the small .bss before the page-aligned data, and an assertion fails the link when less than 4 KiB is left.

Known limits. None of them is a regression. Before this PR, the log always declared SHA-1 and SHA-256, and in each case below it is no worse than that:

• On a CRB TPM the query always fails, because crb_recv() does not read the reply, so the log falls back to the old two banks.
• The AMDSL build starts the log while the PSP keeps locality 2 locked, so the query fails there too, with the same fallback.
• On a TPM with more than five allocated banks, unknown algorithms included, the query fails, with the same fallback.
• A bank of an algorithm the SKL does not know is left out of the log, as every bank but SHA-1 and SHA-256 was before.
• In a bank the SKL cannot hash, PCR 17 does not replay from the log, because SKINIT extends the real digest there. Before this PR, such a bank was not in the log at all. Linux replays only the records after its start marker, so it is not affected.

The first three commits apply unchanged to skl-loader-amdsl-noblob. The link.lds commit needs a rebase there, because that branch changes the linker script too.

Testing:

• The CI matrix (gcc and clang-14, 32 and 64 bit, LTO on and off, the tests and scan-build) passes in an Ubuntu 22.04 container. make run-test-event_log runs the new hosted test for two, one and three banks and the fallback.
• The AMDSL build, signed in an Ubuntu 20.04 container, passes and fails in the same configurations as skl-loader-amdsl-v11 without this PR.
• In QEMU with drtm-tests, which emulates AMD SKINIT, every Linux and Xen launch boots with a TPM that has SHA-1 and SHA-256, only SHA-256, or SHA-1, SHA-256 and SHA-384. Their logs declare the TPM's banks and replay to PCR 18, and to PCR 17 once the SKINIT record carries the real SLB digest (see the last limit above). The Xen launches with only SHA-256 also need x86/tpm.c: skip TPM2 digests the event log does not list xen#35, which the test image had.