Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
Hi Brian, Do you have other TXT capable server or vPro brand client machine, any commercial laptops or desktops are OK, I have HP EliteDesk SFF 800 to run tboot. Maybe your 2600 server needs a BIOS update or so, I guess. Regards, -ning -Original Message- From: Brian Luckau [mailto:brian.luc...@hpe.com] Sent: Tuesday, January 24, 2017 8:35 AM To: g...@enjellic.com; Sun, Ning <ning@intel.com>; 'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net> Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms The error code comes from the console output when we boot with UEFI enabled, and Intel TXT enabled. It happens sometime before the reset happens. We are loading the AC module via the bios as far as I can tell. I went to try to download a new one so that I could try to specify it in the grub2 modules but for our processor there did not seem to be a match listed. This was a few weeks ago, but I remember concluding that for this board and processor, it was expected for it to be loaded from the BIOS and no download was available. On 01/22/2017 11:18 AM, Dr. Greg Wettstein wrote: > On Jan 17, 3:24pm, Brian Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat > platforms > > Good Brian, et.al., I hope the weekend has gone well for everyone. > >> Thanks for your responses. I did not forget, just had to juggle some >> priorities. > No problem, everyone is swamped. > >> The board we have is Intel s2600KP. I believe the board is custom I'm >> told it is not a custom bios implementation. >> >> I can tell you the TPM version is currently 1.2. >> >> For the TXT machine Model -- How do we find this out?) Is this a >> technical specification of the TPM chip or something more general >> like saying "what kind of machine is this? Sorry about the confusion. >> >> The micro-architercture is Haswell (Intel(R) Xeon(R) CPU E5-2660 v3). > So it is an Intel 2600 series server board. > > The server class motherboards should have their Authenticated Code > Module (ACM) loaded from BIOS. Is this correct or are you specifying > an ACM module in your boot configuration? > > If you are not specifying the ACM in the boot stack you may want to > try downloading the ACM for this platform class, presumably a 4th > generation module and trying that to see if there is any difference in > behavior. > > If the board is indeed 'custom' this may be the root of the problem as > the ACM carries out platform verification checks which may not succeed > in the presence of a 'custom' hardware configuration. > >> Here is the information that was near the beginning of boot.message: >> >> [0.00] ACPI: RSDP 7b7d6014 00024 (v02 INTEL ) > So this is the Root System Description Pointer (RSD) message from a > standard boot. Where did the following message come from which you > previously quoted? > >>>>>> .00] ACPI BIOS Error (bug): A valid RSDP was not found >>>>>> (20150930/tbxfroot-243) > As I noted previously the error code which you posted decodes as > follows: > > Class-C/Major-8/Minor-0 - 'Invalid RSDP' > > This in combination with the above 'ACPI BIOS Error' message indicates > the ACM is probably resetting the board because it believes there is > something wrong with the ACPI implementation on the board. > > Ning, any reflections from Intel? > > Dr. Greg > > }-- End of excerpt from Brian Luckau > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > -- > "We trained hard..but every time we were beginning to > form up into > teams, we would be reorganised. I was to learn later in life that we > tend to meet any new situations by reorganising... and a > wonderful process it can be for creating the illusion of progress, > while producing inefficiency and demoralisation." > -- Petronius (6 AD) -- 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
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
On Jan 17, 3:24pm, Brian Luckau wrote: } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms Good Brian, et.al., I hope the weekend has gone well for everyone. > Thanks for your responses. I did not forget, just had to juggle some > priorities. No problem, everyone is swamped. > The board we have is Intel s2600KP. I believe the board is custom > I'm told it is not a custom bios implementation. > > I can tell you the TPM version is currently 1.2. > > For the TXT machine Model -- How do we find this out?) Is this a > technical specification of the TPM chip or something more general like > saying "what kind of machine is this? Sorry about the confusion. > > The micro-architercture is Haswell (Intel(R) Xeon(R) CPU E5-2660 > v3). So it is an Intel 2600 series server board. The server class motherboards should have their Authenticated Code Module (ACM) loaded from BIOS. Is this correct or are you specifying an ACM module in your boot configuration? If you are not specifying the ACM in the boot stack you may want to try downloading the ACM for this platform class, presumably a 4th generation module and trying that to see if there is any difference in behavior. If the board is indeed 'custom' this may be the root of the problem as the ACM carries out platform verification checks which may not succeed in the presence of a 'custom' hardware configuration. > Here is the information that was near the beginning of boot.message: > > [0.00] ACPI: RSDP 7b7d6014 00024 (v02 INTEL ) So this is the Root System Description Pointer (RSD) message from a standard boot. Where did the following message come from which you previously quoted? > >>>> .00] ACPI BIOS Error (bug): A valid RSDP was not found > >>>> (20150930/tbxfroot-243) As I noted previously the error code which you posted decodes as follows: Class-C/Major-8/Minor-0 - 'Invalid RSDP' This in combination with the above 'ACPI BIOS Error' message indicates the ACM is probably resetting the board because it believes there is something wrong with the ACPI implementation on the board. Ning, any reflections from Intel? Dr. Greg }-- End of excerpt from Brian Luckau As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "We trained hard..but every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situations by reorganising... and a wonderful process it can be for creating the illusion of progress, while producing inefficiency and demoralisation." -- Petronius (6 AD) -- 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
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
On Jan 10, 4:01pm, Brian E Luckau wrote: } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms Good morning Brian, I hope this note finds your day going well. > I'm not quite certain where we stand here. I'm trying it again on > the same system (ACM module loaded by the BIOS) and have downloaded > the latest source tree which would give me version 1.9.5 plus some > later commits. Note that it is not actually related to Red Hat, it > is on all platforms I have tested so far. The evidence you provided suggests your problem has nothing to do with the version of tboot you are using. Just for clarification, when you say 'all platforms' are you talking about multiple hardware platforms or multiple Linux distributions? Also, can you tell us what micro-architecture this platform is, ie. Broadwell, Skylake, Westmere etc. > Is there a next step? (I'm sure there is a high likelyhood that I > missed something and someone might need to give me a heads up on > some information I still did not gather). I believe your hardware platform has some type of ACPI table issue which the ACM module doesn't understand and thus resets the hardware when the GETSEC[SENTER] leaf instruction is called to execute the ACM. I'm reproducing below the last e-mail which I sent which contained an analysis of what I believe is going on. Read through and understand it carefully and then capture and post the ACPI table information along with answers to the above questions and hopefully we can make some progress on figuring out what is going on. Let us know if you have any questions. Dr. Greg --- > >> .00] ACPI BIOS Error (bug): A valid RSDP was not found > >> (20150930/tbxfroot-243) > >> > >> - I applied the patch. I haven't seen a difference, but I have > >> encountered the reset after handing off to the kernel, as you > >> mentioned. I will watch for that in the future. > > > > I think the above information explains the ACM reset you are seeing. > > > > The log message that you quote above, 'ACPI BIOS Error...', is > > important. It comes from the the following file/function in the Linux > > ACPI interpreter: > > > > drivers/acpi/acpica/tbxfroot.c:acpi_find_root_pointer() > > > > This suggests that Linux cannot locate the Root System Descriptor > > Pointer (RSDP) for the ACPI implementation. Intel wrote and donated > > the ACPI implementation for Linux so it would be safe to assume that > > they are using similar code and methods in the ACM module. > > > > Ning hasn't replied with definitive documentation regarding the reset > > codes for your platform, but as I noted in my previous e-mail, the > > above findings are consistent with the explanation for your ACM > > TXT.ERRCODE value which I derived from the 4th and 5th generation ACM > > documentation. > > > > The error code your system reports is Class-C/Major-8/Minor-0 which is > > defined as 'Invalid RSDP'. > > > > So there is a high probability that the ACM is issueing a platform > > reset since it is detrmining that there is something wrong with the > > platform ACPI implemention. > > > > One of the things you might want to try is to boot the system without > > TXT, ie. just a standard boot. > > > > Once the system comes up issue the following command: > > > > dmesg > boot.messages > > > > Look to see if there are messages which are similar to the following: > > > > ACPI: Early table checksum verification disabled > > ACPI: RSDP 0x000F05B0 24 (v02 ALASKA) > > ACPI: XSDT 0x876F70A8 CC (v01 ALASKA A M I01072009 AMI > > 00010013) > > .. > > .. > > > > This will give us information as to whether or not Linux has access to > > any ACPI/BIOS information and what the implementation looks like. > > > > I'm almost a little surprised that a platform like this even boots and > > runs without a valid ACPI implementation. You said your system wasn't > > exactly 'off the rack'. Without further information it is difficult > > to say more but I suspect it might be running some type of custom BIOS > > implementation which is at the root of your TXT problem. --- }-- End of excerpt from Brian E Luckau As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
I'm not quite certain where we stand here. I'm trying it again on the same system (ACM module loaded by the BIOS) and have downloaded the latest source tree which would give me version 1.9.5 plus some later commits. Note that it is not actually related to Red Hat, it is on all platforms I have tested so far. Is there a next step? (I'm sure there is a high likelyhood that I missed something and someone might need to give me a heads up on some information I still did not gather). On 09/13/2016 02:11 AM, Dr. Greg Wettstein wrote: > On Sep 9, 3:58pm, Brian E Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > > Good morning Brian, I hope this note finds your week going well. > > Thanks for fowarding along the following information it is very > enlightening as to the issues you are facing. > >> - We are indeed using multiboot and loading the kernel then the initrd > Just as I thought, then you should keep the patch applied that I > forwarded, just to make sure you do not exercise the null pointer > dereference bug which I discussed in my last mail. > >> - This is not an SSI system, not exactly "off the rack" either, but it >> is not one of the specialized systems you are speaking of. >> >> - With TXT enabled, I do not see any references to RSDP. I had some >> output that was still in my buffer from when TXT was not enabled. When I >> search RSDP This is what I see: >> >> .00] ACPI BIOS Error (bug): A valid RSDP was not found >> (20150930/tbxfroot-243) >> >> - I applied the patch. I haven't seen a difference, but I have >> encountered the reset after handing off to the kernel, as you >> mentioned. I will watch for that in the future. > I think the above information explains the ACM reset you are seeing. > > The log message that you quote above, 'ACPI BIOS Error...', is > important. It comes from the the following file/function in the Linux > ACPI interpreter: > > drivers/acpi/acpica/tbxfroot.c:acpi_find_root_pointer() > > This suggests that Linux cannot locate the Root System Descriptor > Pointer (RSDP) for the ACPI implementation. Intel wrote and donated > the ACPI implementation for Linux so it would be safe to assume that > they are using similar code and methods in the ACM module. > > Ning hasn't replied with definitive documentation regarding the reset > codes for your platform, but as I noted in my previous e-mail, the > above findings are consistent with the explanation for your ACM > TXT.ERRCODE value which I derived from the 4th and 5th generation ACM > documentation. > > The error code your system reports is Class-C/Major-8/Minor-0 which is > defined as 'Invalid RSDP'. > > So there is a high probability that the ACM is issueing a platform > reset since it is detrmining that there is something wrong with the > platform ACPI implemention. > > One of the things you might want to try is to boot the system without > TXT, ie. just a standard boot. > > Once the system comes up issue the following command: > > dmesg > boot.messages > > Look to see if there are messages which are similar to the following: > > ACPI: Early table checksum verification disabled > ACPI: RSDP 0x000F05B0 24 (v02 ALASKA) > ACPI: XSDT 0x876F70A8 CC (v01 ALASKA A M I01072009 AMI > 00010013) > .. > .. > > This will give us information as to whether or not Linux has access to > any ACPI/BIOS information and what the implementation looks like. > > I'm almost a little surprised that a platform like this even boots and > runs without a valid ACPI implementation. You said your system wasn't > exactly 'off the rack'. Without further information it is difficult > to say more but I suspect it might be running some type of custom BIOS > implementation which is at the root of your TXT problem. > >> - I do have trousers, installed, nscd running, etc. (but of course >> it only gets to a point where I can check that if I boot without >> EFI) Here are the results with EFI disabled: > When you say you boot without EFI are you saying that you enable > 'legacy' boot? > > If the machine won't boot at all with EFI boot enabled that may be > secondary to the ACPI implementation being problematic as we discussed > above. > >> I did see an index defined at 0x5001 and 0x5003. How many bytes >> am I supposed to read from them? I did it without the -s. > By default those utilities should read the size of the index from the > NVram definition, so you should have gotten everything in the index > with your commands. > >> Here are some attempts : >> # tpm_nvinfo -n >> The following NVRAM areas hav
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
On Sep 9, 3:58pm, Brian E Luckau wrote: } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms Good morning Brian, I hope this note finds your week going well. Thanks for fowarding along the following information it is very enlightening as to the issues you are facing. > - We are indeed using multiboot and loading the kernel then the initrd Just as I thought, then you should keep the patch applied that I forwarded, just to make sure you do not exercise the null pointer dereference bug which I discussed in my last mail. > - This is not an SSI system, not exactly "off the rack" either, but it > is not one of the specialized systems you are speaking of. > > - With TXT enabled, I do not see any references to RSDP. I had some > output that was still in my buffer from when TXT was not enabled. When I > search RSDP This is what I see: > > .00] ACPI BIOS Error (bug): A valid RSDP was not found > (20150930/tbxfroot-243) > > - I applied the patch. I haven't seen a difference, but I have > encountered the reset after handing off to the kernel, as you > mentioned. I will watch for that in the future. I think the above information explains the ACM reset you are seeing. The log message that you quote above, 'ACPI BIOS Error...', is important. It comes from the the following file/function in the Linux ACPI interpreter: drivers/acpi/acpica/tbxfroot.c:acpi_find_root_pointer() This suggests that Linux cannot locate the Root System Descriptor Pointer (RSDP) for the ACPI implementation. Intel wrote and donated the ACPI implementation for Linux so it would be safe to assume that they are using similar code and methods in the ACM module. Ning hasn't replied with definitive documentation regarding the reset codes for your platform, but as I noted in my previous e-mail, the above findings are consistent with the explanation for your ACM TXT.ERRCODE value which I derived from the 4th and 5th generation ACM documentation. The error code your system reports is Class-C/Major-8/Minor-0 which is defined as 'Invalid RSDP'. So there is a high probability that the ACM is issueing a platform reset since it is detrmining that there is something wrong with the platform ACPI implemention. One of the things you might want to try is to boot the system without TXT, ie. just a standard boot. Once the system comes up issue the following command: dmesg > boot.messages Look to see if there are messages which are similar to the following: ACPI: Early table checksum verification disabled ACPI: RSDP 0x000F05B0 24 (v02 ALASKA) ACPI: XSDT 0x876F70A8 CC (v01 ALASKA A M I01072009 AMI 00010013) .. .. This will give us information as to whether or not Linux has access to any ACPI/BIOS information and what the implementation looks like. I'm almost a little surprised that a platform like this even boots and runs without a valid ACPI implementation. You said your system wasn't exactly 'off the rack'. Without further information it is difficult to say more but I suspect it might be running some type of custom BIOS implementation which is at the root of your TXT problem. > - I do have trousers, installed, nscd running, etc. (but of course > it only gets to a point where I can check that if I boot without > EFI) Here are the results with EFI disabled: When you say you boot without EFI are you saying that you enable 'legacy' boot? If the machine won't boot at all with EFI boot enabled that may be secondary to the ACPI implementation being problematic as we discussed above. > I did see an index defined at 0x5001 and 0x5003. How many bytes > am I supposed to read from them? I did it without the -s. By default those utilities should read the size of the index from the NVram definition, so you should have gotten everything in the index with your commands. > Here are some attempts : > # tpm_nvinfo -n > The following NVRAM areas have been defined: > 0x1001 (268435457) > 0x1000f000 (268496896) I'm not sure what the above two contain. > 0x5003 (1342177283) > 0x5001 (1342177281) These two are the ones we were interested in finding. The 0x5001 is the Platform Supplier (PS) NVram index. The 0x5003 is the AUX index for late Ivy Bridge and later platforms. So your board OEM has configured the TXT basics on the system. Running the contents of the AUX register through lcp2_crtpol isn't all that interesting so I elided that from my response. Your findings with respect to the PS index are interesting. > # lcp2_crtpol --show 5001.txt > Error: invalid policy version: 0x202 > > policy data file: 5001 > Error: policy data file signature invalid (): > > # cat 5001.txt | hexdump > 000 0202 0100 > 010 > 020 0201 0403 0605 0807 0a09
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
- We are indeed using multiboot and loading the kernel then the initrd - This is not an SSI system, not exactly "off the rack" either, but it is not one of the specialized systems you are speaking of. - With TXT enabled, I do not see any references to RSDP. I had some output that was still in my buffer from when TXT was not enabled. When I search RSDP This is what I see: .00] ACPI BIOS Error (bug): A valid RSDP was not found (20150930/tbxfroot-243) - I applied the patch. I haven't seen a difference, but I have encountered the reset after handing off to the kernel, as you mentioned. I will watch for that in the future. - I do have trousers, installed, nscd running, etc. (but of course it only gets to a point where I can check that if I boot without EFI) Here are the results with EFI disabled: I did see an index defined at 0x5001 and 0x5003. How many bytes am I supposed to read from them? I did it without the -s. Here are some attempts : # tpm_nvinfo -n The following NVRAM areas have been defined: 0x1001 (268435457) 0x1000f000 (268496896) 0x5003 (1342177283) 0x5001 (1342177281) # tpm_nvread -i 0x5001 -f 5001.txt Successfully wrote data from NVRAM area 0x5001 (1342177281) to file. # tpm_nvread -i 0x5003 -f 5003.txt Successfully wrote data from NVRAM area 0x5003 (1342177283) to file. # lcp2_crtpol --show 5001.txt Error: invalid policy version: 0x202 policy data file: 5001 Error: policy data file signature invalid (): # lcp2_crtpol --show 5003.txt Error: invalid policy version: 0x0 policy data file: 5003.txt Error: policy data file signature invalid (): # cat 5003.txt | hexdump 000 8000 0624 2015 b002 0100 010 020 b19f ee7e 4027 331c bc24 ce3d 6be7 410c 030 8d98 9408 040 db7a 7e19 c8c5 2734 566b e94e 94ef 0f67 050 d520 1c65 060 # cat 5001.txt | hexdump 000 0202 0100 010 020 0201 0403 0605 0807 0a09 0c0b 0e0d 030 100f 1211 1413 036 On 09/03/2016 11:09 AM, Dr. Greg Wettstein wrote: > On Sep 2, 12:49pm, Brian E Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > > Good morning, I hope the weekend is going well for everyone. > > Our Golden Retriever Izzy and I went for a long walk yesterday and we > thought about all of this a bit. Some reflections below to move the > agenda forward for SGI and possibly others who are seeing ACM resets. > >> OK, it looks like we are at TPM 1.2. > OK, very good, that simplifies things a bit as TPM2 systems are a bit > of a wildcard at this point in time. > > I assume you have the Trousers Package installed and the tcsd daemon > running? That will be necessary to interrogate the status of the > NVram indexes. > >> TXT.ERRORCODE: 0xc00010c1 > Safayet from GE already responded and indicated this decodes to the > following error code sequence: > > Class-C/Major-8/Minor-0 > > More on that below. > >> It is a XEON CPU E5 2660 v3 @ 2.60GHZ. It looks like it loads the SINIT >> / AC module loads from the BIOS. >> >> As for chipset: Intel Corporation C610/X99 > So this is a Westmere based server which should be about 2-4 years old > or so. I'm assuming this is an off the rack system and not one of > SGI's specialized Single-System-Image nodes? > > I note with interest the following blog post from April of 2014 on > Intel's ACM site: > > "For Xeon E5-2650 (Intel C600 chipset) the SINIT module is embedded in > the BIOS. The error code documentation hasn't been provided. Please > make available the XEON E5-2650 documenttion." > > A review of the site doesn't seem to suggest the documentation was > ever placed on the site or made available. Ning does Intel have this > information available someplace, if so could you provide a pointer to > it for the list? If not, could you provide a decode of the value in > the TXT.ERRCODE register which Brian provided, as I assume you have > access to the documentation internally. > > Absent definitive documentation from Intel, I reviewed the SINIT > documentation from the 4th (Haswell) and 5th (Broadwell) generation > chipsets as a point of reference. The Class-C category of ACM errors > are ACPI class check errors. More specifically Major-8/Minor-0 is > labelled as 'Invalid RSDP'. > > It appears as if the ACM developers keep these error encodings > reasonably standard across chipset generations. Assuming this is the > case we can proceed forward with some handwaving. > > Within ACPI parlance RSDP is the Root System Description Pointer which > is pretty f
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
OK, it looks like we are at TPM 1.2. TXT.ERRORCODE: 0xc00010c1 It is a XEON CPU E5 2660 v3 @ 2.60GHZ. It looks like it loads the SINIT / AC module loads from the BIOS. As for chipset: Intel Corporation C610/X99 How do you find the PS and AUX NVRAM index? Also I am not implementing any policies, at least not on purpose. On 09/02/2016 11:12 AM, Sun, Ning wrote: > *Intel: https://github.com/01org/TPM2.0-TSS > *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools > *IBM: http://sourceforge.net/projects/ibmtpm20tss/ > > > Regards, > -NIng > > -Original Message- > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > Sent: Friday, September 02, 2016 6:51 AM > To: Brian E Luckau <bluc...@sgi.com>; 'tboot-devel@lists.sourceforge.net' > <tboot-devel@lists.sourceforge.net> > Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > > On Sep 1, 5:11pm, Brian E Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > >> Hi, > Good morning Brian, I hope your day is starting out well. > > Also greetings to Safayet from GE who I see responded downthread as well. I > will integrate his comments below. > >> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or >> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly >> and the last thing we see before the reboot is: >> >> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, >> num_pages=32 >> TBOOT: The maximum allowed MTRR range size=256 Pages >> TBOOT: executing GETSEC[SENTER]... >> >> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS >> is able to boot to completion. >> >> Is this a known issue? > Welcome to SMX development and debugging... :-) > > As Safayet commented, the last line is the tboot hypervisor issueing the > SENTER leaf instruction to initiate execution of the Authenticated Code > Model. Since the ACM is specifically designed to prevent it from being > debugged or examined, the only information available is if the ACM deigns to > place an errorcode in the TXT.ERRCODE SMX register. > > Unfortunately we are tracking a similar problem (ACM platform reset on > GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which > gives one virtually nothing to go on. It would be very helpful if you could > get the TXT.ERRCODE value for everyone to look at if it is other then zero, > if it is zero that would be a significant finding in and of itself. > Secondly, could you provide a full description of the platform you are > attempting to implement your MLE on? Hardware vendor, processor family > (Broadwell, Skylake, other et.al), chipset and whether or not the hardware > has a TPM1.2 or a TPM2 chip. It would also be helpful to know the exact name > of the ACM module which you are loading. > > Thirdly, it would be helpful to know if you are implementing a Platform Owner > (PO) Launch Control Policy (LCP) and what version and type of the policy you > are implementing. Based on our reading of the TXT/SDM, the lcp2_crtpol > utility provided with the tboot distribution is not capable of generating a > valid LCPv3 control policy if the ACM is processing it as we believe it > should be. > > If you would like to proceed forward independently on debugging this, check > to see whether the Platform Supplier (PS) and AUX NVRAM ind (PS) and AUX > NVRAM index > ex locations are defined. If you are on a TPM1.2 based system the PS index > should be at 0x5001 and the AUX will be at 0x5002 on platforms which > are Ivy Bridge and older and 0x5003 on platforms after that. If you are > on a TPM2 based system we will be really interested in chatting with you. > > If you have PS and AUX registers defined, delete your PO NVram location and > try booting the system only with the PS and AUX indexes/registers. I believe > the standard practice is for OEM board manufacturers to configure an ANY > policy in the PS index, which doesn't convey any practical security > guarantees but will usually result in a successful MLE. > > Just for the record we have been working for nine months to get a TXT/MLE > working on TPM2 based Broadwell platforms. To spare everyone some anguish > there is no support for manipulating or managing TPM2 based NVram indexes in > the tboot package. We built tooling on top of a library which we created > from the TSE utilities which Ken Goldman's lab at IBM has released. > > We are currently seeing the same system reset on GETSEC[SENTER] which Brian > is reporting. The reset only occurs if a PO policy is supplied, which is > leading us to believe that t
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
*Intel: https://github.com/01org/TPM2.0-TSS *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools *IBM: http://sourceforge.net/projects/ibmtpm20tss/ Regards, -NIng -Original Message- From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] Sent: Friday, September 02, 2016 6:51 AM To: Brian E Luckau <bluc...@sgi.com>; 'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net> Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms On Sep 1, 5:11pm, Brian E Luckau wrote: } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > Hi, Good morning Brian, I hope your day is starting out well. Also greetings to Safayet from GE who I see responded downthread as well. I will integrate his comments below. > Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or > CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly > and the last thing we see before the reboot is: > > TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, > num_pages=32 > TBOOT: The maximum allowed MTRR range size=256 Pages > TBOOT: executing GETSEC[SENTER]... > > In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS > is able to boot to completion. > > Is this a known issue? Welcome to SMX development and debugging... :-) As Safayet commented, the last line is the tboot hypervisor issueing the SENTER leaf instruction to initiate execution of the Authenticated Code Model. Since the ACM is specifically designed to prevent it from being debugged or examined, the only information available is if the ACM deigns to place an errorcode in the TXT.ERRCODE SMX register. Unfortunately we are tracking a similar problem (ACM platform reset on GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which gives one virtually nothing to go on. It would be very helpful if you could get the TXT.ERRCODE value for everyone to look at if it is other then zero, if it is zero that would be a significant finding in and of itself. Secondly, could you provide a full description of the platform you are attempting to implement your MLE on? Hardware vendor, processor family (Broadwell, Skylake, other et.al), chipset and whether or not the hardware has a TPM1.2 or a TPM2 chip. It would also be helpful to know the exact name of the ACM module which you are loading. Thirdly, it would be helpful to know if you are implementing a Platform Owner (PO) Launch Control Policy (LCP) and what version and type of the policy you are implementing. Based on our reading of the TXT/SDM, the lcp2_crtpol utility provided with the tboot distribution is not capable of generating a valid LCPv3 control policy if the ACM is processing it as we believe it should be. If you would like to proceed forward independently on debugging this, check to see whether the Platform Supplier (PS) and AUX NVRAM index locations are defined. If you are on a TPM1.2 based system the PS index should be at 0x5001 and the AUX will be at 0x5002 on platforms which are Ivy Bridge and older and 0x5003 on platforms after that. If you are on a TPM2 based system we will be really interested in chatting with you. If you have PS and AUX registers defined, delete your PO NVram location and try booting the system only with the PS and AUX indexes/registers. I believe the standard practice is for OEM board manufacturers to configure an ANY policy in the PS index, which doesn't convey any practical security guarantees but will usually result in a successful MLE. Just for the record we have been working for nine months to get a TXT/MLE working on TPM2 based Broadwell platforms. To spare everyone some anguish there is no support for manipulating or managing TPM2 based NVram indexes in the tboot package. We built tooling on top of a library which we created from the TSE utilities which Ken Goldman's lab at IBM has released. We are currently seeing the same system reset on GETSEC[SENTER] which Brian is reporting. The reset only occurs if a PO policy is supplied, which is leading us to believe that the ACM processing of an LCPv3 PO policy is flawed. As I noted above the tboot utilities are not capable of producing a valid policy, at least according to our read of the documentation. > --Brian Luckau I hope the above information is useful. Be glad that you are not trying to do SGX development as that is a completely different can of worms :-)( We will be interested in your findings. Have a good holiday wekeend. Greg }-- End of excerpt from Brian E Luckau As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com ---
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
On Sep 1, 5:11pm, Brian E Luckau wrote: } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > Hi, Good morning Brian, I hope your day is starting out well. Also greetings to Safayet from GE who I see responded downthread as well. I will integrate his comments below. > Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or > CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots > constantly and the last thing we see before the reboot is: > > TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32 > TBOOT: The maximum allowed MTRR range size=256 Pages > TBOOT: executing GETSEC[SENTER]... > > In centOS 7.2, if I disable Intel TXT in the BIOS then at least the > OS is able to boot to completion. > > Is this a known issue? Welcome to SMX development and debugging... :-) As Safayet commented, the last line is the tboot hypervisor issueing the SENTER leaf instruction to initiate execution of the Authenticated Code Model. Since the ACM is specifically designed to prevent it from being debugged or examined, the only information available is if the ACM deigns to place an errorcode in the TXT.ERRCODE SMX register. Unfortunately we are tracking a similar problem (ACM platform reset on GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which gives one virtually nothing to go on. It would be very helpful if you could get the TXT.ERRCODE value for everyone to look at if it is other then zero, if it is zero that would be a significant finding in and of itself. Secondly, could you provide a full description of the platform you are attempting to implement your MLE on? Hardware vendor, processor family (Broadwell, Skylake, other et.al), chipset and whether or not the hardware has a TPM1.2 or a TPM2 chip. It would also be helpful to know the exact name of the ACM module which you are loading. Thirdly, it would be helpful to know if you are implementing a Platform Owner (PO) Launch Control Policy (LCP) and what version and type of the policy you are implementing. Based on our reading of the TXT/SDM, the lcp2_crtpol utility provided with the tboot distribution is not capable of generating a valid LCPv3 control policy if the ACM is processing it as we believe it should be. If you would like to proceed forward independently on debugging this, check to see whether the Platform Supplier (PS) and AUX NVRAM index locations are defined. If you are on a TPM1.2 based system the PS index should be at 0x5001 and the AUX will be at 0x5002 on platforms which are Ivy Bridge and older and 0x5003 on platforms after that. If you are on a TPM2 based system we will be really interested in chatting with you. If you have PS and AUX registers defined, delete your PO NVram location and try booting the system only with the PS and AUX indexes/registers. I believe the standard practice is for OEM board manufacturers to configure an ANY policy in the PS index, which doesn't convey any practical security guarantees but will usually result in a successful MLE. Just for the record we have been working for nine months to get a TXT/MLE working on TPM2 based Broadwell platforms. To spare everyone some anguish there is no support for manipulating or managing TPM2 based NVram indexes in the tboot package. We built tooling on top of a library which we created from the TSE utilities which Ken Goldman's lab at IBM has released. We are currently seeing the same system reset on GETSEC[SENTER] which Brian is reporting. The reset only occurs if a PO policy is supplied, which is leading us to believe that the ACM processing of an LCPv3 PO policy is flawed. As I noted above the tboot utilities are not capable of producing a valid policy, at least according to our read of the documentation. > --Brian Luckau I hope the above information is useful. Be glad that you are not trying to do SGX development as that is a completely different can of worms :-)( We will be interested in your findings. Have a good holiday wekeend. Greg }-- End of excerpt from Brian E Luckau As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Those who will not study history are doomed to debug it." -- Barry Shein -- -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] reset after GETSEC[SENTER] on redhat platforms
If this is the last thing you see, there is likely an error being detected by the SINIT ACM module. To understand the cause of the error, take a look at the Intel TXT error register. There are many ways of doing this. The following is one way. After the system reboots, boot into regular Linux (no TBoot, no Hypervisor). Assuming you installed the full TBoot package, you should have additional binaries installed, such as txt-stat and parse_err. Run parse_err and see what error code you get. Also, if you downloaded your SINIT ACM as a zip file from the Intel website, it should have come with an additional PDF document that tells you how to parse the 32-bit error value. happy debugging, Safayet -Original Message- From: Brian E Luckau [mailto:bluc...@sgi.com] Sent: Thursday, September 01, 2016 7:11 PM To: 'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net> Subject: EXT: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms Hi, Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly and the last thing we see before the reboot is: TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32 TBOOT: The maximum allowed MTRR range size=256 Pages TBOOT: executing GETSEC[SENTER]... In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS is able to boot to completion. Is this a known issue? --Brian Luckau -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tboot-2Ddevel=CwICAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=31O_1ud4qXOENZh5xtrfQYA4v15IwXMivzk5SIQP0_4=cI322K4DrqyXtMEymn2b7uYfBaMYtZDN2Adm5me2wKU= -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
Hi, Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly and the last thing we see before the reboot is: TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32 TBOOT: The maximum allowed MTRR range size=256 Pages TBOOT: executing GETSEC[SENTER]... In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS is able to boot to completion. Is this a known issue? --Brian Luckau -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
