On 08/06/2016 01:27 PM, Dr. Greg Wettstein wrote: > On Aug 6, 5:24am, Chris Laprise wrote: > } Subject: Re: [tboot-devel] Crash/system reset with linux 4.4 > > Hi, I hope the weekend is going well for everyone. > >> Thanks. I don't know why Fedora (Qubes dom0) hasn't updated tboot in >> their repo; I'll try a newer version as your feedback suggests. > In the Qubes environment tboot is starting the Xen hypervisor rather > then the Linux kernel directly, as would be the case with a stock > Ubuntu setup. The dom0 kernel is in the multiboot load stack but the > hypervisor is responsible for configuring and setting up the domain > execution environment which the kernel will run in. > > It is thus somewhat of a stretch to infer the behavior of a stock > kernel boot to that of even the same kernel in a Qubes environment. > > Just as a clarification for the readers of the list, when you say the > tboot-based boot sequence 'fails with a system reset', where does the > system reset occur? Does the Authenticated Code Module (ACM) reset > the system post GETSEC/SENTER, does the Xen hypervisor itself crash or > does the hypervisor reboot itself secondary to a dom0 launch failure?
Hi, I do not have an RS232 serial port for close inspection, and I think the other affected users are in the same situation. However, I did try console=vga for Xen and that allowed me to take a video of the output (unfortunately, the screen quickly clears whether or not reboot is disabled). A transition at "*** LOADING DOMAIN 0 ***" is reached, then two memory tables (physical and virtual) are shown. The last two lines shown before the screen goes dark and system halt/reset are: (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs (XEN) ................................. If you would like, I could type in some of the log output (I haven't been able to capture 100% on video). > The actual tboot footprint inside of the Linux kernel is fairly > minimal. Basically enough infrastructure to probe for and access the > tboot reserved memory region and to handle the re-validation of the > environment secondary to the system going into and out of sleep state. > > Doing this requires the e820 memory map to be interrogated by dom0. > In the case of a Qubes launch, by the time the Linux kernel does this > it is dealing with a memory map which has been manipulated by both > tboot and the Xen hypervisor. The fact that the min_ram setting has a > remediative effect on this regression suggests this is some type of > issue with physical memory layout management. > > Getting a handle on these system launch failures requires getting > console logging out of tboot, Xen and the dom0 kernel, either through > a physical or AMT mediated serial console. At a minimum, set the > reboot=no flag on the hypervisor, in the case of simple VGA logging > that will at least tell you if this is a dom0 launch failure and what > the hypervisor was doing in the lead up to the failure. > > Knowing Joanna Rutkowska's reputation, I'm assuming that Qubes is > running with a Launch Control Policy (LCP) which verifies the > integrity of the boot stack. As you are debugging these issues make > sure that the operative LCP is updated after any command-line > parameters have been changed, otherwise you will end up trading the > reset you are debugging with an ACM reset secondary to an LCP > verification error. If what you mean is that an LCP is defined to make the system halt when the ACM's conditions aren't met, then I believe the answer is 'no' (but ITL staff know this better than I). The anti-evil-maid feature which is utilizing TXT here amounts to a user-enforced verification step that hinges on whether a user-supplied secret phrase can be unsealed and displayed; The user can choose to continue booting when verification fails. > >> Chris > I hope the above is helpful. > > And yes, we have spent lots of time working on tboot problems... :-) > > Have a good week. > > Greg > > }-- End of excerpt from Chris Laprise > > 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 > ------------------------------------------------------------------------------ > "Man, despite his artistic pretensions, his sophistication and many > accomplishments, owes the fact of his existence to a six-inch layer of > topsoil and the fact that it rains." > -- Anonymous writer on perspective. > GAUSSIAN quote. > Thanks for your input, Greg! Regards, Chris ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
