[tboot-devel] TBOOT on a PowerEdge R730 with a TPM2.0

[Miguel M. <mig...@ua...>]

Hi,

Lately I've been trying to get tboot to work on a Dell PowerEdge R730 with the latest bios (v2.15.0). In v2.15.0 the BIOS and SINIT ACM were updated to v3.1.5_20211209 according to the Dell change log. The machine is equiped with a TPM2.0 and prior to the following tests no actions were taken with it (important for later).

So, I installed tboot (v1.9.12) and the default policy worked straight away.
First thing that I noticed was that it was looking for a VLP at NVIndex 0x01200001 but didn't show where it was looking for the LCP. From reading the manuals and some other mailing lists (this one for example: https://sourceforge.net/p/tboot/mailman/message/36754984/) and from the information presented by tboot I reached this conclusion:

My TPM2.0 NVIndex Set is 0 based on the information below:

TBOOT:       TPM info list:
TBOOT:             TPM capability:
TBOOT:                  ext_policy: 0x3
TBOOT:                  tpm_family : 0x3
TBOOT:                  tpm_nv_index_set : 0x0
TBOOT:             alg count: 3
TBOOT:                 alg_id: 0x4
TBOOT:                 alg_id: 0xb
TBOOT:                 alg_id: 0x14

Therefore the relevant TPM2 NVRAM indexes are as follows (also supported by tboot/common/tpm_20.c line 2795-2798):

PS:  0x1800001
PO:  0x1400001
AUX: 0x1800003
SGX: 0x1800004

Thus based on this I should write the LCP into nvindex 0x1400001.
The problem is that if I check the current capabilities of my TPM2.0 it presents me with this information:

tpm2_getcap handles-nv-index
- 0x1400001
- 0x1400002
- 0x1C00002
- 0x1C00003
- 0x1C00004
- 0x1C0000A
- 0x1C0000B
- 0x1C0000C
- 0x1C10102
- 0x1C10103
- 0x1C10104
- 0x1C10105

tpm2_nvreadpublic 0x1400001
0x1400001:
  name: 000be7351a9ff0c7de635f31d6bd6a1d0fe6f123316614138dc3c743c78bf30edb1f
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ppwrite|authwrite|write_stclear|ppread|authread|no_da|written|platformcreate|read_stclear
    value: 0x54005E2
  size: 32

This , as far as my knowledge goes, tells me I can't clear or write to it since it is established by, in this case, Dell.

For sanity of mind I also tried the new index (0x1c10106) but it would end up with an error ("An issue is observed in the previous invocation of TXT SINIT Authenticated Code Module (ACM) because the TXT
information stored in the TPM chip may be corrupted.") during boot. I confirmed the information presented in the tpm with the tools used for generating (--show --verbose) and nothing was corrupted, so this index is clearly not the one I want.


So, what should regarding this issue? Or where should I place the LCP?

I'm using the following commands for generating and written the LCP to the TPM.

lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory" /boot/tboot.gz > mle_hash
lcp2_crtpolelt --create --type mle2 --minver 17 --alg sha256 --out mle.elt mle_hash
tb_polgen --create --alg sha256 --type continue vl.pol
tb_polgen --add --num 0 --pcr 19 --hash image --cmdline "$(</proc/cmdline) intel_iommu=on noefi" --image "/boot/vmlinuz-$(uname -r)" vl.pol
tb_polgen --add --num 1 --pcr 20 --hash image --image "/boot/initrd-$(uname -r)" vl.pol
lcp2_crtpolelt --create --type custom --out vl.elt --uuid tboot vl.pol
lcp2_crtpollist --create --listver 0x300 --out list_unsig.lst mle.elt pcr.elt vl.elt
cp list_unsig.lst list_sig.lst
lcp2_crtpollist --sign 0x8 --sigalg rsapss --hashalg sha256 --pub pub.pem --priv priv.pem --out list_sig.lst
lcp2_crtpol --create --alg sha256 --polver 3.2 --type list --pol list.pol --data list.data list_sig.lst
tpm2_nvdefine -s $(( 38 + 32 )) -a 'ownerwrite|policywrite|authread|no_da' 0x01400001
tpm2_nvwrite -i list.pol 0x01400001
sudp cp list.data /boot

Since I couldn't find (and hope to find out what is the problem with this mail), instead of writting the LCP I write the VLP (vl.pol) to 0x01200001. The server can reboot and the system will extend, in this specific case, the PCR 19 with the kernel+cmdline and PCR 20 with the initrd+cmdline. If I change either the kernel or the initrd the system still boots as expected (since I have policy of continue instead of halt) and the PCR will have different values (as expected) but the TBOOT tool says the "TXT Measured Launch: True" when I expected it to to be false. Am I miss-interpreting the normal behaviour of TXT here? Also, is this VLP (without the LCP) enough for remote attestation? I'd say yes since pcr 17-20 have all the required information and they can't be altered by an bad actor due to their locality requirements.