Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
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: >> >> .00] 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 0x000F05B0 24 (v02 ALASKA) > ACPI: XSDT 0x876F70A8 CC (v01 ALASKA A M I01072009 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 0x5001 and 0x5003. 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 hav
[tboot-devel] null pointer dereference bug in tboot Linux loader
In a previous thread, I was given this patch by Dr. Wettstein. I was trying to
integrate it into our test build of tboot, but we like to leave a commment that
shows a trail with regards to where it came from. (we want to make it clear why
a patch is being done, where it came from, how official it is, etc.)
I can't seem to find this in the tboot code tree. Is it there and I'm missing
it? If it is not there, does the trunk need to be updated with this patch?
=
"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 @0x10
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.cWed 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,
_entry_point, is_measured_launch);"
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] TPM 2.0 + TXT + EFI tboot
Is that likely to also help an issue I am having where it reboots after getsec[SENTER] every time I have EFI enabled? We are on a BIOS that has the AC Init module built into the BIOS. On 12/08/2016 05:00 PM, Sun, Ning wrote: In grub.cfg, find the line “multiboot2 /boot/tboot.gz logging=serial,memory”, add extpol=sha256 at end of the line. *From:* travis.gilb...@dell.com [mailto:travis.gilb...@dell.com] *Sent:* Thursday, December 08, 2016 2:23 PM *To:* tboot-devel@lists.sourceforge.net *Subject:* [tboot-devel] TPM 2.0 + TXT + EFI tboot I am trying to perform a simple trusted boot on SLES 12 SP2 with TPM 2.0 and EFI mode. I can verify that TXT works using getsec64.efi and performing SENTER, setting the secrets flag, rebooting and doing SENTER then SEXIT. When I select the “tboot 1.9.4” entry in grub2, my server pauses for a bit after the loading initial RAM disk step and then reboots. I then get an SINIT error notification from BIOS that points to a log error (ERR_BAD_LOG_POINTER_PTR2_MATCH). I am working with a freshly provisioned TPM and a new install of SLES 12 SP2. I added the tboot and tpm2.0-tools packages to that install and modified grub2 to give me a tboot prompt (I think I added a file grub-tboot to /etc/default/ to accomplish this). Am I missing anything? -- 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 -- 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
[tboot-devel] garbage characters on the command line
Hi, We have had issues with tboot 1.8.x and 1.9.4, and seeing garbage characters on the cmdline at the end. We've seen this on multiple different hardware types, different OSes(RHEL 7.3, Centos 7.2, SLES12sp2). We are using PXE boot in all the cases that I'm aware of. It looks like we are passing tboot a good command line and then tboot passes control to the kernel, at which time the command line has the extra characters on it. TBOOT: verifying module " (tftp)/boot/sles12sp2/vmlinuz-4.4.21-69-default MAC=[snipped]... [...] crashkernel=256M"... TBOOT: OK : d6 ce 7b 29 41 a3 3a d9 3a b8 1a 69 55 88 9b 66 49 4c 80 66 TBOOT: verifying module " (tftp)/boot/sles12sp2/initrd-4.4.21-69-default"... Then it transfers control to the kernel. At this point the kernel shows that the cmdline it got is corrupted. [0.00] Linux version 4.4.21-69-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Tue Oct 25 10:58:20 UTC 2016 (9464f67) [0.00] Command line: (tftp)/boot/sles12sp2/vmlinuz-4.4.21-69-default [snipped ... ] crashkernel=256Mt ufh I'm hoping to find there is a patch, etc. for tboot to rectify this. -- 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
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
- 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: .00] 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 0x5001 and 0x5003. 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: 0x1001 (268435457) 0x1000f000 (268496896) 0x5003 (1342177283) 0x5001 (1342177281) # tpm_nvread -i 0x5001 -f 5001.txt Successfully wrote data from NVRAM area 0x5001 (1342177281) to file. # tpm_nvread -i 0x5003 -f 5003.txt Successfully wrote data from NVRAM area 0x5003 (1342177283) to file. # lcp2_crtpol --show 5001.txt Error: invalid policy version: 0x202 policy data file: 5001 Error: policy data file signature invalid (): # lcp2_crtpol --show 5003.txt Error: invalid policy version: 0x0 policy data file: 5003.txt Error: policy data file signature invalid (): # cat 5003.txt | hexdump 000 8000 0624 2015 b002 0100 010 020 b19f ee7e 4027 331c bc24 ce3d 6be7 410c 030 8d98 9408 040 db7a 7e19 c8c5 2734 566b e94e 94ef 0f67 050 d520 1c65 060 # cat 5001.txt | hexdump 000 0202 0100 010 020 0201 0403 0605 0807 0a09 0c0b 0e0d 030 100f 1211 1413 036 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 f
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
OK, it looks like we are at TPM 1.2. TXT.ERRORCODE: 0xc00010c1 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 How do you find the PS and AUX NVRAM index? Also I am not implementing any policies, at least not on purpose. On 09/02/2016 11:12 AM, Sun, Ning wrote: > *Intel: https://github.com/01org/TPM2.0-TSS > *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools > *IBM: http://sourceforge.net/projects/ibmtpm20tss/ > > > Regards, > -NIng > > -Original Message- > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > Sent: Friday, September 02, 2016 6:51 AM > To: Brian E Luckau <bluc...@sgi.com>; 'tboot-devel@lists.sourceforge.net' > <tboot-devel@lists.sourceforge.net> > Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > > On Sep 1, 5:11pm, Brian E Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > >> Hi, > Good morning Brian, I hope your day is starting out well. > > Also greetings to Safayet from GE who I see responded downthread as well. I > will integrate his comments below. > >> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or >> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly >> and the last thing we see before the reboot is: >> >> TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, >> num_pages=32 >> TBOOT: The maximum allowed MTRR range size=256 Pages >> TBOOT: executing GETSEC[SENTER]... >> >> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS >> is able to boot to completion. >> >> Is this a known issue? > Welcome to SMX development and debugging... :-) > > As Safayet commented, the last line is the tboot hypervisor issueing the > SENTER leaf instruction to initiate execution of the Authenticated Code > Model. Since the ACM is specifically designed to prevent it from being > debugged or examined, the only information available is if the ACM deigns to > place an errorcode in the TXT.ERRCODE SMX register. > > Unfortunately we are tracking a similar problem (ACM platform reset on > GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which > gives one virtually nothing to go on. It would be very helpful if you could > get the TXT.ERRCODE value for everyone to look at if it is other then zero, > if it is zero that would be a significant finding in and of itself. > Secondly, could you provide a full description of the platform you are > attempting to implement your MLE on? Hardware vendor, processor family > (Broadwell, Skylake, other et.al), chipset and whether or not the hardware > has a TPM1.2 or a TPM2 chip. It would also be helpful to know the exact name > of the ACM module which you are loading. > > Thirdly, it would be helpful to know if you are implementing a Platform Owner > (PO) Launch Control Policy (LCP) and what version and type of the policy you > are implementing. Based on our reading of the TXT/SDM, the lcp2_crtpol > utility provided with the tboot distribution is not capable of generating a > valid LCPv3 control policy if the ACM is processing it as we believe it > should be. > > If you would like to proceed forward independently on debugging this, check > to see whether the Platform Supplier (PS) and AUX NVRAM ind (PS) and AUX > NVRAM index > ex locations are defined. If you are on a TPM1.2 based system the PS index > should be at 0x5001 and the AUX will be at 0x5002 on platforms which > are Ivy Bridge and older and 0x5003 on platforms after that. If you are > on a TPM2 based system we will be really interested in chatting with you. > > If you have PS and AUX registers defined, delete your PO NVram location and > try booting the system only with the PS and AUX indexes/registers. I believe > the standard practice is for OEM board manufacturers to configure an ANY > policy in the PS index, which doesn't convey any practical security > guarantees but will usually result in a successful MLE. > > Just for the record we have been working for nine months to get a TXT/MLE > working on TPM2 based Broadwell platforms. To spare everyone some anguish > there is no support for manipulating or managing TPM2 based NVram indexes in > the tboot package. We built tooling on top of a library which we created > from the TSE utilities which Ken Goldman's lab at IBM has released. > > We are currently seeing the same system reset on GETSEC[SENTER] which Brian > is reporting. The reset only occurs if a PO policy is supplied, which is > leading us to believe that t
Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
Hi, Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly and the last thing we see before the reboot is: TBOOT: setting MTRRs for acmod: base=0x7bf0, size=0x2, num_pages=32 TBOOT: The maximum allowed MTRR range size=256 Pages TBOOT: executing GETSEC[SENTER]... In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS is able to boot to completion. Is this a known issue? --Brian Luckau -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] no console will be available to OS
Thank you for the tips. I had indeed been trying to get output on serial as well but not getting anything. I got serial output to happen successfully this time; this is my current line in grub.cfg: multiboot2 /tboot.gz /tboot.gz logging=serial,memory,vga loglvl=all serial=115200,8n1,0x2f8 Now I'm able to get more information on serial (after adding that serial= entry) It turns out it is hanging at TBOOT: transfering control to kernel @0x100... SO... I would venture to say people who write in with the "no console will be available to OS" problem are barking up the wrong tree, like I was. If you can get the serial output then more might come to light about what is really happening. We may need to try this on better TXT-enabled hardware with the right BIOS. However, I'm confused at the fact that it hangs here if we are using UEFI but not if we are using legacy grub. I'm accustomed to the system booting regardless of whether you have the hardware, bios, etc. for it. You just would not get a measured boot. So, still scratching my head here. -- Brian On 07/31/2016 01:54 PM, Brian Luckau wrote: Re: [tboot-devel] no console will be available to OS Will try that when I Wade back onto it again. Last week tried we could get it to work with legacy bios but not EFI -Original Message- *From: *Jason Zaman [ja...@perfinion.com <mailto:ja...@perfinion.com>] *Sent: *Sunday, July 31, 2016 09:51 AM Central Standard Time *To: *Justin King-Lacroix *Cc: *tboot-devel@lists.sourceforge.net *Subject: *Re: [tboot-devel] no console will be available to OS On Fri, Jul 29, 2016 at 01:01:46PM -0700, Justin King-Lacroix wrote: > Nope, doesn't work on (at least) recent Lenovo laptops. Tried it a few > weeks back. > > Getting the same "WARNING: no console will be available to OS" on 1.9.4, > too. > > On 29 July 2016 at 09:26, Sun, Ning <ning@intel.com> wrote: > > > There is a latest tboot 1.9.4 to download on sourceforge > > https://sourceforge.net/projects/tboot/ > > You can collect tboot output through serial port in a UEFI boot. > > For install and run tboot in UEFI, you also can follow the wiki here > > https://sourceforge.net/p/tboot/wiki/Home/. > > README in tboot source code tree is very helpful as well. > > Hope this helps. > > > > -ning > > > > -Original Message- > > From: Brian E Luckau [mailto:bluc...@sgi.com] > > Sent: Thursday, July 28, 2016 3:21 PM > > To: tboot-devel@lists.sourceforge.net > > Subject: [tboot-devel] no console will be available to OS > > > > Hi, > > > > I have tried searching the archives with no luck. When I try to use tboot > > with UEFI, it gives me: > > > > Loading tboot 1.8.1 > > WARNING: no console will be available to OS Loading Linux > > 3.10.0-327.el7.x86_64 Loading initial ramdisk ... > > > > Then nowhere. I have tried using console=tty0, console=ttyS1,115200 and > > various different variations of this. You need to use something like this: loglvl=all logging=memory,serial serial=115200,8n1,0x30b0 console= is a linux cmdline option. tboot needs serial=. also you need to find the hex addr of the serial port which Ive forgotten how to do. that addr is for my the AMT serial thing on my Lenovo T440s -- Jason > > > > My colleagues and I have not been able to get tboot to work on EFI > > platforms. I am sure there may be something wrong with our config but we > > are flying blind. How do others deal with this when it occurs? > > > > > > > > -- > > ___ > > tboot-devel mailing list > > tboot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > > > > -- > > ___ > > tboot-devel mailing list > > tboot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > -- > ___ > tboot-devel mailing list > tboot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tboot-devel -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel -- _
[tboot-devel] no console will be available to OS
Hi, I have tried searching the archives with no luck. When I try to use tboot with UEFI, it gives me: Loading tboot 1.8.1 WARNING: no console will be available to OS Loading Linux 3.10.0-327.el7.x86_64 Loading initial ramdisk ... Then nowhere. I have tried using console=tty0, console=ttyS1,115200 and various different variations of this. My colleagues and I have not been able to get tboot to work on EFI platforms. I am sure there may be something wrong with our config but we are flying blind. How do others deal with this when it occurs? -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
