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.
_______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
