> -----Original Message----- > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > Sent: Wednesday, December 14, 2016 03:21 > To: Gilbert, Travis <travis_gilb...@dell.com>; tboot- > de...@lists.sourceforge.net > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > On Dec 13, 7:56pm, <travis.gilb...@dell.com> wrote: > } Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > Good morning, I hope the week is going well for everyone. > > > > -----Original Message----- > > > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > > > Sent: Friday, December 9, 2016 02:33 > > > To: Gilbert, Travis <travis_gilb...@dell.com>; tboot- > > > de...@lists.sourceforge.net > > > Cc: bluc...@sgi.com > > > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > > > > > If possible, could you provide some feedback on the hardware > > > platform you are working on. I'm assuming it is a Dell box of some > > > sort... :-) I'm also assuming it is vPro compliant, with hardware > > > TPM2 and that you are able to successfully access the TPM2 hardware > > > from a standard Linux boot and read NVram, dump PCR's etc? > > > Yes, I can list PCRs and read NV RAM with the tpm2-tools package. I > > can read PCR contents with the TPM vendor's tools. > > Very good, so you have userspace access to the TPM2 device, it must be an > ACPI-MSFT0101/tpm_tis device if you are using a stock SUSE distribution. I'm > assuming this is a Broadwell based hardware platform? > > > > For your reference purposes, I see that you are attempting an EFI > > > based boot, have you tried to demonstrate a successful measured > > > launch environment (MLE) with legacy boot enabled? We are currently > > > able to demonstrate a successful, but minimal, MLE with legacy boot > > > on our Broadwell NUC5i5MYBE development platforms. We are currently > > > avoiding EFI due to complexity and firmware vagary issues. > > > > I have not tried this on legacy boot. > > > > > I see that Ning Sun from Intel replied downthread as well and > > > recommended that you restrict algorithm agility to SHA256 with the > > > extpol=sha256 command-line directive to tboot. We have been using > > > that for months in our minimal boot environment but that doesn't get > > > us past where we are currently blocked on more advanced MLE > configurations. > > > > Adding extpol=sha256 got me a successful regular (non-MLE) tboot > > (thank you Ning Sun!). My first attempt at an MLE policy failed. It > > appears BootGuard is getting involved and puts me in a reboot loop. > > > > I had to do a reinstall of SLES 12 SP2 to get the extpol fix to work. > > All I added (plus dependencies that were auto-detected) to the base > > Xen install was tboot, tpm2.0-tools, and tpm2-0-tss. Then I added the > > "extpol=sha256" to my /etc/grub.d/20_linux_tboot, ran "grub2-mkconfig > > -o /boot/grub2/grub.cfg", and rebooted. I may have had to run > > "grub2-install /dev/sda" as well. > > So in your case you have a successful EFI tboot running secondary to the > specification of the algorithm policy to be used. I'm assuming your > successful > boot is only when the Platform Supplier (PS) NVram index location is > populated. In your case that should be NVram handle 0x1c10103, based on > your comments below.
Yes, PS is provisioned. > I'm assuming when you attempt to install an MLE policy the ACM resets your > test platform? Does your EFI/BIOS or tboot provide an ACM error code on > the next boot cycle. In the case of tboot you can find the code by looking > for > the following in the boot log: > > TBOOT: TXT.ERRCODE: HEXNUMBER > > Where HEXNUMBER will be the TXT error termination code. I hadn't thought of that due to the reboot loop. I tried using our utilities to read the error code, but it looks like it was wiped by the time I got out of the reboot loop. I can't get to the OS load, I'm rebooting before that so there's no Linux boot log. > > > Secondly, do you have a Platform Owner Launch Control Policy PO/LCP > > > defined? You can check this by seeing whether or not the NVram > > > index location 0x1400001 has been defined. I'm assuming your > > > hardware/ACM environment is not so new that it would be using the > > > newer 0x1c10106 index location. > > > We are using the 0x1c10106 location for PO. > > Interesting, is the ACM supplied by the BIOS or are you loading the ACM via > tboot? If the answer to the latter question is yes what ACM module are you > using? ACM is part of BIOS, it's an Intel provided ACM. > I'm assuming you are attempting to load a PO/ANY policy? What tool are you > using to generate and load the binary policy into the > 0x1c10106 NVram index? The PO/ANY policy didn't appear to do anything on my system. For that I used "Tpm2PoProv.nsh SHA256 Example" though someone else mentioned a more explicitly named script that I'm looking for. Here's the script I'm running. It's supposed to be an unsigned simple hashing policy. #!/bin/sh tpm2_takeownership -o new -e new -l new lcp2_mlehash --verbose --create --alg sha256 --cmdline "logging=serial,memory extpol=sha256" tboot.gz > tboot_hash lcp2_crtpolelt --verbose --create --type mle --alg sha256 --ctrl 0x00 --minver 0 --out tbootmle.elt tboot_hash lcp2_crtpollist --verbose --create --out lists1_unsig.lst tbootmle.elt lcp2_crtpol --verbose --create --type list --pol lists1.pol --alg sha256 --data lists1.data lists1_unsig.lst tpm2_nvwrite -x 0x1c10106 -a 0x40000001 -P new -f lists1.pol > If you have a basic PS/ANY MLE working you are at the same point we are at > on TPM2/TXT platforms. We get an ACM platform reset in GETSEC[SENTER] > when the PO index is loaded with an ANY policy. > Neither the TXT.ERRCODE register nor the 0x1200002 NVram index (TBOOT > error index) contain any indication of why the reset occurred, ie. the error > value is 0. > > We've had some positive feedback on organizing a TPM2/TXT conference > call, are you interested in joining that? Sure. I'm still coming up to speed on both, but this effort has been a crash course. > Have a good day. > > Greg > > }-- End of excerpt from <travis.gilb...@dell.com> > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102 development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > ------------------------------------------------------------------------------ > "Don't worry about people stealing your ideas. If your ideas are any good, > you'll have to ram them down people's throats." > -- Howard Aiken > > -- > > ------------------------------------------------------------------------------ > 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
