>From: Sant Y [mailto:satish.va...@gmail.com] 
>Sent: Friday, July 20, 2018 05:03
>To: tboot-devel@lists.sourceforge.net
>Subject: [tboot-devel] Fwd: TXT/TPM 2.0 and tboot Launch control policy
>
>Hello tboot devs! 
>
>I wish to revive this old discussion, on generating LCP for TPM2. There were 
>at least 2 threads I found in this list, however none of them seem to have 
>anything conclusive.
>
>A tboot with the default policies are working, however, for a policy with MLE 
>it fails.
>
>For writing to the NV index I use the tpm2-tss tools.
>As for tboot, I use the current sources from the development branch, compiled 
>and installed. I follow the steps mostly like in this discussion : 
>https://sourceforge.net/p/tboot/mailman/message/35942299/

Please post the exact commands you're using.

Are you in a UEFI environment?

You'll have to do something like the following:
#echo GRUB_TBOOT_POLICY_DATA="list.data" > /etc/default/grub-tboot

In order to have grub actually verify the LCP. You also need to modify your 
grub-mkconfig file for the GRUB_CMDLINE_TBOOT option to add "extpol=sha256". 
Then you have to run "grub2-mkconfig -o /boot/grub2/grub.cfg" to re-generate 
your grub.cfg file with the changes.

My relevant line is the following:
# Command line for tboot itself
: ${GRUB_CMDLINE_TBOOT='logging=serial,memory extpol=sha256'}

The vga/video logging option didn't work for me, but is sometimes in the 
default options. The grub-mkconfig that I have will strip that option out of a 
UEFI boot if it's there.

>The current lcp2_crtpol requires the signing algorithm, for which I supply 0x8 
>(RSA 2048, SHA256). I get the following for listing the created policy file 
>
># lcp2_crtpol --show list.pol 
>policy file: list.pol
>     version: 0x300
>     hash_alg: sha256
>     policy_type: list
>     sinit_min_version: 0x0
>     data_revocation_counters: 0, 0, 0, 0, 0, 0, 0, 0, 
>     policy_control: 0x0
>     max_sinit_min_ver: 0x0
>     max_biosac_min_ver: 0x0
>     lcp_hash_alg_mask: 0x8
>     lcp_sign_alg_mask: 0x8
>     aux_hash_alg_mask: 0x8
>     policy_hash: ff 0d 04 10 6d 45 3e e0 98 01 44 b3 65 f2 51 7e 1b 41 1c 50 
>2c e3 9e d9 64 c4 8b 22 ff 66 fd c0 
>
>However, the parse of policy data file itself fails as seen below
>
># lcp2_crtpol --show list.data 
>Error: invalid policy version: 0x6e49
>
>policy data file: list.data
>     file_signature: Intel(R) TXT LCP_POLICY_DATA
>     num_lists: 1
>     list 0:
>         version: 0x200
>         sig_alg: unknown (16)
>         policy_elements_size: 0x32 (50)
>         policy_element[0]:
>             size: 0x32 (50)
>             type: 'mle' (16)
>             policy_elt_control: 0x00000000
>             data:
>                 sinit_min_version: 0x0
>                 hash_alg: sha256
>                 num_hashes: 1
>                 hashes[0]: f8 c0 05 ec 6c 32 53 48 54 52 47 25 3a 0d c6 4a 03 
> 32 3c 13 
>0e c1 86 ca 33 3b c1 f6 9d 48 04 b3 
>I also did the signing with a 2048 bit RSA key, however the lcp2_crtpol always 
>shows an invalid policy version. 

I've never used the --show option, but it appears it has user-unfriendly 
output. You can pass a policy and policy data or just policy data. If you pass 
just policy data, it can't distinguish between the two and tries to process it 
as a policy first. This fails and gives your error. It then processes the file 
as policy data because processing it as a policy failed. So your "invalid 
policy version" is a red herring. Try passing your policy file and your data 
file and see what the output is.

If you can post at least the data file or both data and policy files, that will 
help us troubleshoot. The main reason is the sig_alg output. The fact that it's 
unknown type isn't surprising (see below about changes needed), but that it's 
printed as decimal 16. That corresponds to TPM_ALG_NULL (0x0010). This makes me 
suspect that you followed the steps in the other thread exactly. That was an 
example of an unsigned policy. This is the reason we need you to post the full 
list of commands you're running to generate everything.

Either way I wouldn't necessarily trust the --show option since I didn't touch 
that code when I updated the lcptools-v2 code and it looks like that whole code 
flow needs updating based on the LCPv3 changes.

>The txt-stat results in this : 
>
>TBOOT:   timeout values: A: 750, B: 2000, C: 75000, D: 750
>TBOOT: SGX:verify_IA32_se_svn_status is called
>TBOOT: SGX is not enabled, cpuid.ebx: 0x21cbfbb
>TBOOT: reading Verified Launch Policy from TPM NV...
>TBOOT:  :70 bytes read
>TBOOT:  :reading failed
>TBOOT: reading Launch Control Policy from TPM NV...
>TBOOT:  :70 bytes read
>TBOOT: in unwrap_lcp_policy
>TBOOT: v2 LCP policy data found
>TBOOT:  :reading failed
>TBOOT: failed to read policy from TPM NV, using default
>TBOOT: TPM: write NV 01200002, offset 00000000, 00000004 bytes, return value = 
>0000018B
>TBOOT: Error: write TPM error: 0x18b.
>The ':reading failed' is coming from tboot/common/policy.c where it does a 
>verify_policy() and it fails. So the problem is indeed with the policy 
>creation. I cannot troubleshoot it further, as the verify_policy() logs itself 
>are not available from txt-stat.
>
>Finally, I also tried the lcp-gen2 python tool to generate the policy files. 
>However, it's a bit confusing to use, the file pickup dialogs doesn't work and 
>there is no option to specify commandline for MLE hash etc. 
>
>Can someone please help with the topic? I'm okay to experiment if anyone has 
>patches to deal with this. 
> Some details on my TPM 2.0 is pasted here : https://pastebin.com/FEdf3ZTQ 
>
>Regards,
>Sant
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Reply via email to