- 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:
.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 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 0x50000001 and 0x50000003. 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:
0x10000001 (268435457)
0x1000f000 (268496896)
0x50000003 (1342177283)
0x50000001 (1342177281)
# tpm_nvread -i 0x50000001 -f 50000001.txt
Successfully wrote data from NVRAM area 0x50000001 (1342177281) to file.
# tpm_nvread -i 0x50000003 -f 50000003.txt
Successfully wrote data from NVRAM area 0x50000003 (1342177283) to file.
# lcp2_crtpol --show 50000001.txt
Error: invalid policy version: 0x202
policy data file: 50000001
Error: policy data file signature invalid ():
# lcp2_crtpol --show 50000003.txt
Error: invalid policy version: 0x0
policy data file: 50000003.txt
Error: policy data file signature invalid ():
# cat 50000003.txt | hexdump
0000000 0000 8000 0624 2015 b002 0000 0100 ffff
0000010 ffff ffff ffff ffff ffff ffff ffff ffff
0000020 b19f ee7e 4027 331c bc24 ce3d 6be7 410c
0000030 8d98 9408 ffff ffff ffff ffff ffff ffff
0000040 db7a 7e19 c8c5 2734 566b e94e 94ef 0f67
0000050 d520 1c65 ffff ffff ffff ffff ffff ffff
0000060
# 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
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 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
