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. 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. > > 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? 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? 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? 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
