Sry by TXT I meant tboot code..
> On Aug 2, 2017, at 2:09 PM, Xiao Li <xiao.li....@gmail.com> wrote:
>
> Hi Travis,
>
> Thank you so much for the help. I have used similar commands to generate the
> MLE, list file and list.pol. I found it seems that the lcp2-tools are working
> fine generating and reading policy files, but TXT code seems is not able to
> read the LCP:
>
> The policy files I generated with lcp2-tools look good to me.
>
>
> # lcp2_crtpolelt --show tbootmle.elt
> policy element file: tbootmle.elt
> size: 0x32 (50)
> type: 'mle' (16)
> policy_elt_control: 0x00000002
> data:
> sinit_min_version: 0x0
> hash_alg: sha256
> num_hashes: 1
> hashes[0]: 68 4f 08 42 38 81 59 45 ce eb 1a 98 b6 16 21 96 da 3e e2
> 8a
> 3f 37 61 78 9b cb 91 d5 73 de 3f 62
>
> # lcp2_crtpollist --show list_unsig.lst
> policy list file: list_unsig.lst
> version: 0x200
> sig_alg: unknown (16)
> policy_elements_size: 0x32 (50)
> policy_element[0]:
> size: 0x32 (50)
> type: 'mle' (16)
> policy_elt_control: 0x00000002
> data:
> sinit_min_version: 0x0
> hash_alg: sha256
> num_hashes: 1
> hashes[0]: 68 4f 08 42 38 81 59 45 ce eb 1a 98 b6 16 21 96 da 3e e2
> 8a
> 3f 37 61 78 9b cb 91 d5 73 de 3f 62
>
> # 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: 0xa
> aux_hash_alg_mask: 0x8
> policy_hash: 16 f4 8a b0 7f a3 3d 8b 6a 54 31 39 1d c6 c5 f3 f9 46 1d 60
> aa bf 9e d6 95 25 eb c3 cb 55 de 6c
>
>
> However I found the TXT codes seems have problem recognizing the policy when
> reading it from NV index. I have changed some code to force the TXT to read
> the LCP, and I modified the default policy as well for TXT to use if the LCP
> in NV index were failed to read, seems the TXT just believe the read policy
> version to be zero all the time. I have injected some logs in TXT logs (with
> xaol marked, I’ve been using 0x1400001 since using 0x01C10106 just keeps
> reset system after GETSEC SENTER and reset TXT to be disabled, which is also
> very weird for my use case):
>
>
> TBOOT: reading Launch Control Policy from TPM NV... xaol: 0x1400001
> TBOOT: :70 bytes read
> TBOOT: : xaol Policy version, 0x300, compare: 0x202
> TBOOT: : xaol Policy version, 0x300, compare: 0x300
> TBOOT: in unwrap_lcp_policy
> TBOOT: v2 LCP policy data found
> TBOOT: xaol in LCP_POLICY_DATA_FILE_SIGNATURE match
> TBOOT: xaol poldata->num_lists: 1
> TBOOT: xaol elt->type: 0x0
> TBOOT: xaol pollist->version: 0x100
> TBOOT: xaol pollist->version: 0x200
> TBOOT: xaol in pollist->version == LCP_TPM20_POLICY_LIST_VERSION
> TBOOT: xaol Policy 0x300
> TBOOT: policy:
> TBOOT: unsupported version (0)
> TBOOT: version: 0
> TBOOT: policy_type: unsupported (3)
> TBOOT: :reading failed
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> TBOOT: unsupported version (3)
> TBOOT: version: 3
> TBOOT: policy_type: TB_POLTYPE_CONT_NON_FATAL
> TBOOT: hash_alg: TB_HALG_SHA256
> TBOOT: policy_control: 00000001 (EXTEND_PCR17)
> TBOOT: num_entries: 3
> TBOOT: policy entry[0]:
> TBOOT: mod_num: 0
> TBOOT: pcr: none
> TBOOT: hash_type: TB_HTYPE_ANY
> TBOOT: num_hashes: 0
> TBOOT: policy entry[1]:
> TBOOT: mod_num: any
> TBOOT: pcr: 19
> TBOOT: hash_type: TB_HTYPE_ANY
> TBOOT: num_hashes: 0
> TBOOT: policy entry[2]:
> TBOOT: mod_num: nv_raw
> nv_index: 40000010
> TBOOT: pcr: 22
> TBOOT: hash_type: TB_HTYPE_ANY
> TBOOT: num_hashes: 0
> TBOOT: xaol TPM20: write NV 01200002, offset 00000000, 00000004 bytes, return
> value = 0000018B
> TBOOT: Error: write TPM error: 0x18b.
> TBOOT: no policy in TPM NV.
>
> I wonder if you have seen this problem as well? Is TXT having trouble reading
> policy from NVindex in your case?
>
>
> Thanks,
> Xiao
>
>
>> On Aug 1, 2017, at 3:17 PM, travis.gilb...@dell.com
>> <mailto:travis.gilb...@dell.com> wrote:
>>
>> Dell - Internal Use - Confidential
>>
>>> -----Original Message-----
>>> From: Xiao Li [mailto:xiao.li....@gmail.com <mailto:xiao.li....@gmail.com>]
>>> Sent: Sunday, July 23, 2017 19:53
>>> To: Gilbert, Travis <travis_gilb...@dell.com
>>> <mailto:travis_gilb...@dell.com>>
>>> Cc: tboot-devel@lists.sourceforge.net
>>> <mailto:tboot-devel@lists.sourceforge.net>
>>> Subject: Re: [tboot-devel] [patch] TPM2.0 LCPv2 Tool Patch
>>>
>>> Hi Travis,
>>>
>>> Thanks for the patch! I got distracted in the past few days and didn't got
>>> chance to pick my tpm2 with tboot experiments until today.
>>>
>>> I have applied the patch and tried to setup LCP with verification of MLE.
>>> Got a
>>> couple basic questions that I think I'm unclear about when trying to create
>>> a
>>> policy structure:
>>
>> Here's my script for a simple unsigned MLE policy on SLES 12 SP2. Some paths
>> may change if you're using another distro.
>>
>> #!/bin/sh
>> cd /boot
>> tpm2_takeownership -o password -e password -l password
>> tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P password -s 70 -t 0x204000A
>>
>> #TXT - Scenario#1, Single MLE element and Unsigned Policy
>> lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory
>> extpol=sha256" tboot.gz > tboot_hash
>> lcp2_crtpolelt --create --type mle --alg sha256 --ctrl 0x02 --minver 0 --out
>> tbootmle.elt tboot_hash
>> lcp2_crtpollist --create --out lists1_unsig.lst tbootmle.elt
>> lcp2_crtpol --create --type list --pol lists1.pol --alg sha256 --sign 0x0A
>> --data lists1.data lists1_unsig.lst
>> tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P password -f lists1.pol
>> echo GRUB_TBOOT_POLICY_DATA="lists1.data" > /etc/default/grub-tboot
>> grub2-mkconfig -o /boot/grub2/grub.cfg
>>
>>>
>>> * --mask specifies policy hash algorithm, does it mean the hash towards MLE
>>> (like cmdline) or the policy itself?
>>
>> As I understand it, you should be using the same hashing algorithm
>> throughout your definition of the policy. Technically, the mask applies to
>> the policy hashing algorithm. It is an optional algorithm and will
>> automatically convert the hashing algorithm specified in the "--alg"
>> argument to the appropriate policy hash mask if you omit the --mask option.
>>
>>> * --sign specifies the signing algorithm means the signing algorithm for the
>>> policy itself? (say if I use lcp_crtpollist to create a list policy and
>>> sign it with a
>>> pub key generated with openssl genrsa -out signing_key.pem 2048, then I
>>> should specify SIGN_ALG_MASK_RSASSA_2048_SHA256?)
>>
>> Use the signing algorithm you used to sign the policy list (with the
>> lcp2_crtpollist command). You have to specify the --sign argument in
>> hexadecimal or decimal notation. I didn't add string parsing to that
>> argument. Keep in mind that for RSA, this mask as defined by the Intel docs
>> is a combination of the policy hashing algorithm and the signing algorithm.
>> It can be an ORing of any or all of the algorithms specified in
>> LCP_APPROVED_SIGNATURE_ALG. So a valid mask for the openssl command you
>> gave, not knowing whether you used SHA-256 or SHA-1 for the policy hashing
>> algorithm, would be 0x0C (0x08 | 0x04).
>>
>>>
>>>
>>> After failed a couple of times I remembered Greg and Marco mentioned
>>> about that I need to use gen2 to setup MLE (instead of lcp2_mlehash,
>>> lcp2_crtpolelt)... I guess I'm wondering what would be the capability of
>>> patched version of lcp2_crtpol? Will it be able to handle the payloads
>>> created
>>> for MLE with lcp2_* tools or should I switch to use gen2 tools altogether?
>>
>> You can switch to gen2 tools, but I haven't really used them much. They
>> can't be scripted since it's a GUI-based solution. I was working on the
>> command line versions before the GUI versions existed and only recently
>> figured out the right release procedure for this code.
>>
>>>
>>> I was also trying to modify the default VLCP manually for tpm2 but didn't
>>> how to... I have been thinking if it means I could manually change the code
>>> snippet
>>>
>>> <source>
>>> /* default policy */
>>> static const tb_policy_t _def_policy = {
>>> version : 2,
>>> policy_type : TB_POLTYPE_CONT_NON_FATAL,
>>> hash_alg : TB_HALG_SHA1,
>>> policy_control : TB_POLCTL_EXTEND_PCR17,
>>> num_entries : 3,
>>> entries : {
>>> { /* mod 0 is extended to PCR 18 by default, so don't re-extend it
>>> */
>>> mod_num : 0,
>>> pcr : TB_POL_PCR_NONE,
>>> hash_type : TB_HTYPE_ANY,
>>> num_hashes : 0
>>> },
>>> { /* all other modules are extended to PCR 19 */
>>> mod_num : TB_POL_MOD_NUM_ANY,
>>> pcr : 19,
>>> hash_type : TB_HTYPE_ANY,
>>> num_hashes : 0
>>> },
>>> { /* NV index for geo-tagging will be extended to PCR 22 */
>>> mod_num : TB_POL_MOD_NUM_NV_RAW,
>>> pcr : 22,
>>> hash_type : TB_HTYPE_ANY,
>>> nv_index : 0x40000010,
>>> num_hashes : 0
>>> }
>>> }
>>> };
>>> </source>
>>>
>>> to hardcode any cmdline/image hashes and change the policy type to HALT?
>>>
>>> Thanks in advance and wish everyone had a nice weekend :)
>>>
>>> Best,
>>> Xiao
>>>
>>>
>>>
>>> On Wed, Jul 19, 2017 at 10:16 AM, <travis.gilb...@dell.com
>>> <mailto:travis.gilb...@dell.com>
>>> <mailto:travis.gilb...@dell.com <mailto:travis.gilb...@dell.com>> > wrote:
>>>
>>>
>>> > -----Original Message-----
>>> > From: Gilbert, Travis
>>> > Sent: Wednesday, July 19, 2017 12:02
>>> > To: tboot-devel@lists.sourceforge.net
>>> <mailto:tboot-devel@lists.sourceforge.net> <mailto:tboot-
>>> de...@lists.sourceforge.net <mailto:de...@lists.sourceforge.net>>
>>> > Subject: [tboot-devel] [patch] TPM2.0 LCPv2 Tool Patch
>>> >
>>> > This is a significant patch that corrects omissions I found in the
>>> lcptools-v2
>>> > utilities. It adds definitions based on the Intel TXT Software
>>> Development
>>> > Guide (https://www.intel.com/content/www/us/en/software-
>>> <https://www.intel.com/content/www/us/en/software->
>>> <https://www.intel.com/content/www/us/en/software-
>>> <https://www.intel.com/content/www/us/en/software->>
>>> > developers/intel-txt-software-development-guide.html). I used
>>> Revision
>>> > 013. Looking at Section 4.6 of Revision 014, it seems my patch still
>>> applies.
>>> > Appendix E has a couple changes, notably the removal of ECDSA as
>>> an
>>> > approved signing algorithm. This could be changed from what I'm
>>> providing if
>>> > we want to update the tools to match Revision 014.
>>> >
>>> > I've added the following:
>>> > -Ability to define the allowed policy hashing algorithms (stored in a
>>> mask) -
>>> > Ability to define the signing algorithm -Ability to define the AUX
>>> hashing
>>> > algorithm -constants for hashing and signing algorithms -Ability to
>>> define LCP
>>> > version
>>> >
>>> > I also changed some of the options as well as some of my added
>>> options to
>>> > required based on my experience of ACMs rejecting LCPs without
>>> those
>>> > fields and common sense. For example, the policy hash could be
>>> defined
>>> > without defining the allowed policy hashing algorithms. Now, since
>>> you have
>>> > to define the policy hash, you must also define the policy hashing
>>> "allowed
>>> > algorithms" mask.
>>> >
>>> > Signed-off-by: Travis Gilbert <travis.gilb...@dell.com
>>> <mailto:travis.gilb...@dell.com>
>>> <mailto:travis.gilb...@dell.com <mailto:travis.gilb...@dell.com>> >
>>>
>>>
>>> Please ignore the "Confidential" tag. Outlook "helpfully" adds that to
>>> any email that it's not explicitly excluded from. I've edited my above
>>> message
>>> to reflect that.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>> _______________________________________________
>>> tboot-devel mailing list
>>> tboot-devel@lists.sourceforge.net
>>> <mailto:tboot-devel@lists.sourceforge.net> <mailto:tboot-
>>> de...@lists.sourceforge.net <mailto:de...@lists.sourceforge.net>>
>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>> <https://lists.sourceforge.net/lists/listinfo/tboot-devel>
>>> <https://lists.sourceforge.net/lists/listinfo/tboot-devel>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>> _______________________________________________
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net <mailto:tboot-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
------------------------------------------------------------------------------
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
