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
---------------------------------------------------------------------------
> >> .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.
---------------------------------------------------------------------------
}-- 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 innovation is saying 'no' to 1000 things."
-- Moxie Marlinspike
------------------------------------------------------------------------------
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
