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 wrote:
>
> Dell - Internal Use - Confidential
>
>> -----Original Message-----
>> From: Xiao Li [mailto:xiao.li....@gmail.com]
>> Sent: Sunday, July 23, 2017 19:53
>> To: Gilbert, Travis <travis_gilb...@dell.com>
>> Cc: 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> > wrote:
>>
>>
>> > -----Original Message-----
>> > From: Gilbert, Travis
>> > Sent: Wednesday, July 19, 2017 12:02
>> > To: tboot-devel@lists.sourceforge.net <mailto:tboot-
>> 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->
>> > 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> >
>>
>>
>> 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://sdm.link/slashdot
>> _______________________________________________
>> tboot-devel mailing list
>> tboot-devel@lists.sourceforge.net <mailto:tboot-
>> de...@lists.sourceforge.net>
>> 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://sdm.link/slashdot
> _______________________________________________
> tboot-devel mailing list
> 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
