From: Dr. G. W. <gr...@wi...> - 2016-12-09 09:15:00
|
On Dec 8, 10:22pm, <Tra...@de...> wrote: } Subject: [tboot-devel] TPM 2.0 + TXT + EFI tboot Good morning, I hope this note finds the end of the week going well for everyone. > I am trying to perform a simple trusted boot on SLES 12 SP2 with TPM > 2.0 and EFI mode. I can verify that TXT works using getsec64.efi and > performing SENTER, setting the secrets flag, rebooting and doing > SENTER then SEXIT. When I select the "tboot 1.9.4" entry in grub2, my > server pauses for a bit after the loading initial RAM disk step and > then reboots. I then get an SINIT error notification from BIOS that > points to a log error (ERR_BAD_LOG_POINTER_PTR2_MATCH). > > I am working with a freshly provisioned TPM and a new install of > SLES 12 SP2. I added the tboot and tpm2.0-tools packages to that > install and modified grub2 to give me a tboot prompt (I think I added > a file grub-tboot to /etc/default/ to accomplish this). > > Am I missing anything? We've been working for almost 10 months, albeit intermittently, attempting to get a TPM2/TXT environment operational for our security platforms without complete success. I see that Brian Luckau from SGI commented downthread and it appears they are still struggling to get something working as well. So you folks at Dell are probably not missing anything as much as the fact that we are not convinced that anyone has worked out all of the issues with Trusted Boot on modern Intel hardware, ie. TPM2 based systems. 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? 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 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. 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. The tpm2-tools package should have a utility for dumping out NVram index locations. We wrote our own TPM2 tooling from scratch based on Ken Goldman's TSS2 reference library, which comes out of IBM's TJ Watson labs and which is rock solid from a standards conformance perspective. I can send you a Linux statically linked diagnostic binary if you have problems looking for the PO policy indexes. Provided, of course, that you have basic userspace control of the TPM2 chip in hand. I'm assuming your hardware is implementing a TIS/MSFT0101 ACPI interface? ACPI/CRB support seems to be a big dodgy unless you are using custom rolled Linux kernels. Hopefully the above information is helpful in moving your work forward. We would be interested in any feedback you might have on our questions above. Have a good day. Greg }-- End of excerpt from <Tra...@de...> 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: gr...@en... ------------------------------------------------------------------------------ "If you get to thinkin' you're a person of some influence, try orderin' somebody else's dog around." -- Cowboy Wisdom -- |
From: Dr. G. W. <gr...@wi...> - 2016-12-14 09:21:07
|
On Dec 13, 7:56pm, <Tra...@de...> 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:gr...@wi...] > > Sent: Friday, December 9, 2016 02:33 > > To: Gilbert, Travis <Travis_Gilbert@Dell.com>; tboot- > > de...@li... > > Cc: bl...@sg... > > 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 <Tra...@de...> 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: gr...@en... ------------------------------------------------------------------------------ "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 -- |
From: <Tra...@de...> - 2016-12-14 17:35:22
|
> -----Original Message----- > From: Dr. Greg Wettstein [mailto:gr...@wi...] > Sent: Wednesday, December 14, 2016 03:21 > To: Gilbert, Travis <Travis_Gilbert@Dell.com>; tboot- > de...@li... > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > On Dec 13, 7:56pm, <Tra...@de...> 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:gr...@wi...] > > > Sent: Friday, December 9, 2016 02:33 > > > To: Gilbert, Travis <Travis_Gilbert@Dell.com>; tboot- > > > de...@li... > > > Cc: bl...@sg... > > > 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 <Tra...@de...> > > 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: gr...@en... > ------------------------------------------------------------------------------ > "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 > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: <Tra...@de...> - 2016-12-15 17:37:45
|
Okay new update. I tracked the issue down to the ACM saying the PO hash algorithm mask is 0. Here is the script I'm running to create and write the policy. I'm passing the algorithm in to the lcp2_crtpol command. Why isn't it writing that to the algorithm mask? I'm currently analyzing the policy that was generated to see if, in fact, the hash algorithm mask is 0. #!/bin/bash tpm2_takeownership -o new -e new -l new tpm2_nvdefine -x 0x1c10106 -a 0x40000001 -P new -s 70 -t 0x204000A 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 |
From: <Tra...@de...> - 2016-12-15 20:06:02
|
> -----Original Message----- > From: Gilbert, Travis > Sent: Thursday, December 15, 2016 11:38 > To: tbo...@li... > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > Okay new update. I tracked the issue down to the ACM saying the PO hash > algorithm mask is 0. Here is the script I'm running to create and write the > policy. > > I'm passing the algorithm in to the lcp2_crtpol command. Why isn't it writing > that to the algorithm mask? > > I'm currently analyzing the policy that was generated to see if, in fact, the > hash algorithm mask is 0. The hash algorithm mask is 0. If I write all 1s to that area in my .pol file, I get past the ACM check. There is a bug in lcptools-v2/crtpol.c where none of the alg-masks are ever touched. They exist in the lcp_policy_t2 struct, but they're not initialized to a usable value. They just inherit the value of all zeroes from the memset() call. I'm hacking a patch together to get my testing completed. How would you devs like me to implement that in a final patch? I can make command line arguments to be passed in with those values. I think I should also at least make the default match the algorithm being passed in on the command line. So if you specify "--alg sha256" then lcp_hash_alg_mask should at least match that with 0x0B. If you have preferences for command line argument letters to use, speak up. Otherwise, I'll pick ones that match with lcptools and that make sense. <snip> |
From: Dr. G. W. <gr...@wi...> - 2016-12-15 21:20:41
|
On Dec 15, 8:05pm, <Tra...@de...> wrote: } Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot Good afternoon, I hope the day is going well for everyone. > > -----Original Message----- > > From: Gilbert, Travis > > Sent: Thursday, December 15, 2016 11:38 > > To: tbo...@li... > > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > > > > > algorithm mask is 0. Here is the script I'm running to create and write the > > policy. > > > > I'm passing the algorithm in to the lcp2_crtpol command. Why isn't it writing > > that to the algorithm mask? > > > > I'm currently analyzing the policy that was generated to see if, in fact, the > > hash algorithm mask is 0. > The hash algorithm mask is 0. If I write all 1s to that area in my > .pol file, I get past the ACM check. There is a bug in > lcptools-v2/crtpol.c where none of the alg-masks are ever > touched. They exist in the lcp_policy_t2 struct, but they're not > initialized to a usable value. They just inherit the value of all > zeroes from the memset() call. Travis, I'm glad that you were able to provide independent confirmation on this. Based on the symptoms you were reporting, I suspected you were running into this issue. As I had previously noted a couple of times on this list, the tboot LCP tools cannot produce a valid launch control policy, at least based on the documentation in the TXT SDM and what we were seeing in the field. Ning, this is the issue we reported back in July when we shipped binary dumps of our LC ANY policy to Supreeti while Jeevan was on sabbatical. The ACM which Travis is using must be newer then the Broadwell ACM's since it appears his ACM was able to get him useful diagnostic information. It appears as if the Broadwell ACM is just resetting the platform if it runs into any type of anomaly in the PO/LCP without registering the errorcode in either the hardware error register or the TB error code index. Travis, were you able to get TBOOT to report the error code in the TXT.ERRCODE section of the log or was your BIOS kind enough to give you an indication of what was going on? Secondly, could you confirm that after an LCP error that the TB error index gets populated with the ACM error code. If not this is a bug since these issues are hard enough to debug without getting proper diagnostic information out of a botched boot. > I'm hacking a patch together to get my testing completed. How would > you devs like me to implement that in a final patch? I can make > command line arguments to be passed in with those values. I think I > should also at least make the default match the algorithm being > passed in on the command line. So if you specify "--alg sha256" then > lcp_hash_alg_mask should at least match that with 0x0B. If you have > preferences for command line argument letters to use, speak > up. Otherwise, I'll pick ones that match with lcptools and that make > sense. Given the support of algorithm agility in TPM2 based systems there are two masks which need to be set. One which selects the valid hashing algorithms used for measurement and one which selects the valid hash algorithms for signatures. Technically, the hash algorithm specification arguements to the lcp2_crtpol utility shouldn't affect the population of those two fields, that is a characteristic of the platform. The arguements to the lcp2_crtol utility specify which algorithm is to be used for creation of a specific policy and must be a proper subset of the available algorithms. Ideally, the lcp2_crtpol utility should be reading the PS policy and using the algorithm mask in that to populate the equivalent fields in the PO policy. At least that would be the path least likely to create bad policies. Obviously, the utility should also reject an attempt to specify an algorithm which isn't available, at least in an ideal world where we were trying to be bullet proof. I'm assuming a proper solution to all of this is too late for the 1.9.5 release.... :-( Have a good remainder of the week. Greg }-- End of excerpt from <Tra...@de...> 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: gr...@en... ------------------------------------------------------------------------------ "Remember that when you take down the fishhouse you can't put the minnows back into the lake, so throw them out on the ice. Make sure you stomp on any of the live ones so they don't suffer." -- Fritz Wettstein At the lake -- |
From: <Tra...@de...> - 2016-12-13 19:56:54
|
Dell - Internal Use - Confidential > -----Original Message----- > From: Dr. Greg Wettstein [mailto:gr...@wi...] > Sent: Friday, December 9, 2016 02:33 > To: Gilbert, Travis <Travis_Gilbert@Dell.com>; tboot- > de...@li... > Cc: bl...@sg... > Subject: Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > On Dec 8, 10:22pm, <Tra...@de...> wrote: > } Subject: [tboot-devel] TPM 2.0 + TXT + EFI tboot > > Good morning, I hope this note finds the end of the week going well for > everyone. > > > I am trying to perform a simple trusted boot on SLES 12 SP2 with TPM > > 2.0 and EFI mode. I can verify that TXT works using getsec64.efi and > > performing SENTER, setting the secrets flag, rebooting and doing > > SENTER then SEXIT. When I select the "tboot 1.9.4" entry in grub2, my > > server pauses for a bit after the loading initial RAM disk step and > > then reboots. I then get an SINIT error notification from BIOS that > > points to a log error (ERR_BAD_LOG_POINTER_PTR2_MATCH). > > > > I am working with a freshly provisioned TPM and a new install of SLES > > 12 SP2. I added the tboot and tpm2.0-tools packages to that install > > and modified grub2 to give me a tboot prompt (I think I added a file > > grub-tboot to /etc/default/ to accomplish this). > > > > Am I missing anything? > > We've been working for almost 10 months, albeit intermittently, attempting > to get a TPM2/TXT environment operational for our security platforms > without complete success. I see that Brian Luckau from SGI commented > downthread and it appears they are still struggling to get something working > as well. > > So you folks at Dell are probably not missing anything as much as the fact that > we are not convinced that anyone has worked out all of the issues with > Trusted Boot on modern Intel hardware, ie. TPM2 based systems. > > 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. > 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. > 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. > The tpm2-tools package should have a utility for dumping out NVram index > locations. We wrote our own TPM2 tooling from scratch based on Ken > Goldman's TSS2 reference library, which comes out of IBM's TJ Watson labs > and which is rock solid from a standards conformance perspective. I can send > you a Linux statically linked diagnostic binary if you have problems looking for > the PO policy indexes. > > Provided, of course, that you have basic userspace control of the TPM2 chip > in hand. I'm assuming your hardware is implementing a > TIS/MSFT0101 ACPI interface? ACPI/CRB support seems to be a big dodgy > unless you are using custom rolled Linux kernels. > > Hopefully the above information is helpful in moving your work forward. We > would be interested in any feedback you might have on our questions > above. > > Have a good day. > > Greg > > }-- End of excerpt from <Tra...@de...> > > 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: gr...@en... > ------------------------------------------------------------------------------ > "If you get to thinkin' you're a person of some influence, try orderin' > somebody else's dog around." > -- Cowboy Wisdom > > > -- |