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
