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
--
------------------------------------------------------------------------------
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
