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?
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.
> 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.
--
------------------------------------------------------------------------------
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
