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 fundamental to ACPI being able to work correctly. Occam's
Razor would suggest this is the ACM module getting the error code
wrong rather then an actual invalid RSDP value. Unless of course this
is one of your modified SSI boxes, hence my question above.
However, we found and forwarded a buffer overflow fix to Intel a
couple of years ago which was secondary to the improper parsing of the
RSDP structure. That is fixed in 1.9.4 but it wouldn't be out of the
question if the ACM was using the same library routines as the tboot
code, which means the bug might be in the ACM codebase as well.
If you have serial logging available or if you have a camera to take
pictures of the tboot boot sequence look for the following:
RSDP (v2, NAME() @HEX_NUMBER
Verify that NAME is INTEL and not a six character system name as that
will trip the bug if it persists uncorrected in the ACM.
BTW for those following along at home, this is a great bug. It allows
whoever controls the BIOS to inject up to a 254 byte payload into
system memory after GETSEC[SENTER] has run. Whether it is exploitble
or not is a matter of debate but getting anything into memory of one's
choosing is a huge deal to security aggressors.
A second thing to look at.
Since your E-2650 is loading the ACM from BIOS flash memory I'm
assuming you are running with somewhat of a non-standard multiboot
configuration, at least as compared to a standard desktop
implementation. Could you confirm for the list your boot module load
sequence, I'm assuming it is as follows:
Kernel
Initramfs
There is a null-pointer dereference bug in the tboot Linux loader
which manifests itself as a system reset after the following is
displayed:
TBOOT: transferring control to kernel @0x100000
We picked up on this issue since our embedded systems boot without an
external initramfs. The loader doesn't check the multiboot module
count and as a result uses the value of an uninitialized variable to
copy a random amount of material into kernel memory.
Here is a patch against 1.9.4 which corrects the problem:
---------------------------------------------------------------------------
diff -urNp v1.9.4/tboot-1.9.4/tboot/common/loader.c
tboot-1.9.4/tboot/common/loader.c
--- v1.9.4/tboot-1.9.4/tboot/common/loader.c Wed May 18 12:20:26 2016
+++ tboot-1.9.4/tboot/common/loader.c Sat Sep 3 08:45:55 2016
@@ -1272,10 +1272,19 @@ bool launch_kernel(bool is_measured_laun
MB_MAGIC : MB2_LOADER_MAGIC);
}
else if ( kernel_type == LINUX ) {
- m = get_module(g_ldr_ctx,0);
- void *initrd_image = (void *)m->mod_start;
- size_t initrd_size = m->mod_end - m->mod_start;
+ void *initrd_image;
+ size_t initrd_size;
+ if ( get_module_count(g_ldr_ctx) == 0 ) {
+ initrd_size = 0;
+ initrd_image = 0;
+ }
+ else {
+ m = get_module(g_ldr_ctx,0);
+ initrd_image = (void *)m->mod_start;
+ initrd_size = m->mod_end - m->mod_start;
+ }
+
expand_linux_image(kernel_image, kernel_size,
initrd_image, initrd_size,
&kernel_entry_point, is_measured_launch);
---------------------------------------------------------------------------
If you are in position where you can compile tboot yourself it may be
worth trying this patch to see if it affects your system one way or
another.
We don't have access to systems with a BIOS embedded ACM so we cannot
assess whether or not this problem would affect such systems but it is
obviously worth checking.
> How do you find the PS and AUX NVRAM index?
As I noted above you will need the Trousers package loaded and
operational.
You can first try the following command:
tpm_nvinfo -n
To list the NVram index areas which have been defined. The PS and AUX
indexes should be as follows:
PS: 0x50000001
AUX: 0x50000002 or 0x50000003 (Depending on platform)
If they are defined use the following command to dump out the contents
of those index locations into a file:
tpm_nvread -i 0xNNNNNNNN -f FNAME
You may have to add and fiddle with the '-s' switch to give the size
of the area.
If the indexes are defined and you are able to read them run the
binary file through the lcp2_crtpol in the following form:
lcp2_crtpol --show FNAME
And post the results.
If the lcp2_crtpol utility is unavailable or uncooperative run the
binary file through hexdump and post the results. The PS index will
tell us what type and version of the default Launch Control Policy
that is being interpreted by the ACM.
> Also I am not implementing any policies, at least not on purpose.
That is helpul to know. Confirm that the 0x40000001 index is not
present in the output of the tpm_nvinfo command. If it is try using
the tpm_nvrelease utility to delete the index and test the boot after
deletion of the index.
Hopefully the above is of assistance to you and perhaps other in
better understanding and debugging your ACM reset problem.
We will look forward to your findings.
Have a good week.
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
------------------------------------------------------------------------------
"Don't talk unless you can improve the silence."
-- George Will
--
------------------------------------------------------------------------------
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
