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: >> >> .000000] 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 0x00000000000F05B0 000024 (v02 ALASKA) > ACPI: XSDT 0x00000000876F70A8 0000CC (v01 ALASKA A M I 01072009 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 0x50000001 and 0x50000003. 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: >> 0x10000001 (268435457) >> 0x1000f000 (268496896) > I'm not sure what the above two contain. > >> 0x50000003 (1342177283) >> 0x50000001 (1342177281) > These two are the ones we were interested in finding. > > The 0x50000001 is the Platform Supplier (PS) NVram index. The > 0x50000003 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 50000001.txt >> Error: invalid policy version: 0x202 >> >> policy data file: 50000001 >> Error: policy data file signature invalid (): >> >> # cat 50000001.txt | hexdump >> 0000000 0202 0100 0000 0000 0000 0000 0000 0000 >> 0000010 0000 0000 0000 0000 0000 0000 0000 0000 >> 0000020 0000 0201 0403 0605 0807 0a09 0c0b 0e0d >> 0000030 100f 1211 1413 >> 0000036 > So your PS index is 54 bytes long which is consistent with an LCPv2 > policy. > > The first two octets, '0202', code for a version 2.2 policy file, so > far so good. > > The next (third) byte '01' is the hash function selector code. The > lcp2.h header file only defines a value of '00' which codes for SHA1. > The lcp3.h file defines the value of '01' as selecting SHA256. > However, your policy file seems to contain a 20 byte hash value which > is of course the length of a SHA1 hash. > > So your PS policy is coding for SHA256 but contains a SHA1 value. > > The other strange thing is the fourth byte of the policy codes for the > policy type. Your value, '00', codes for a policy type of LIST. That > is somewhat odd given that there would have to be a file containing a > list of launch control policy elements which this policy file would > preside over. Usually the PS index has a policy type of ANY. > > I'm assuming the checksum in your policy file is the checksum of a > policy list but I'm not sure where that list would be coming from. > You have two other NVram index locations defined, I'm not familiar > with this type of configuration, but perhaps one of those index > locations contain the policy list. Usually an LCP policy list file is > included as part of the multiboot sequence in order to save NVram > space and to increase platform provisioning agility. > > The PS and AUX indexes are usually provisioned by the system OEM. > Intel provides EFI based tools for doing this, do you know who would > have provisioned the indexes and created the PS policy? It isn't > clear how an ACM would be able to successfully prosecute your plaform > policy. > > Given the findings regarding your ACPI implementation, the ACM isn't > even getting a chance to process the policy. If it were to do so I > suspect you would be getting some type of LCP validation error in your > TXT.ERRCODE register. > > The PS and AUX registers can be de-provisioned and rebuilt. Based on > what we are observing with your platform you may need to do that if > you can get past the ACPI induced reset. > > Hopefully the above information is helpful. It will be interesting to > see if you have any ACPI information available on a standard boot. > > Have a good day. > > 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 58102 development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > ------------------------------------------------------------------------------ > "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 > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
