[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.3 development update, and stock-taking

On 17/01/13 14:15, Jan Beulich wrote:
Just to be clear here: are you saying that there is no way to boot Xen directly from EFI with a pvops kernel? if so, that seems like a pretty big deal to me...
It depends on the system: Those ones where legacy methods still
allow finding namely ACPI tables would allow booting. On ones
where those tables can be found only by consulting EFI, booting
is possible, but you'd generally end up without PCI interrupts
(which to me is almost the same as "doesn't boot").

OK; so we're talking about different things. I'm talking about 1) can the binary be loaded into memory by EFI bootloaders 2) can dom0 access EFI runtime services. You're talking about "can it boot", which minimally requires 1, and on some systems (i.e., systems that do not provide appropriate ACPI tables) also requires 2.

So we already have #1 for both xenlinux and pvops; we just need #2. Is that correct?

* Xen able to detect the existence of a signed Linux binary, and leave
EFI boot-time services enabled for dom0 to use when appropriate
No. We can't leave bot services enabled, and we also don't
need to. The model is that only the Dom0 kernel binary needs
validation at the boot loader level. Everything else will be
done in the kernel (including initrd validation, or really the
parts of it that need validation).
As I understood it, the Ubuntu bootloader will not require an image to
be signed to boot.
Yes - the plan is to decide whether booting securely by picking
to boot with or without the shim. All layers above have to
react accordingly. However, it is my understanding that if you
use the shim and your kernel isn't signed, boot will fail.

My understanding was that Ubuntu's shim will load Ubuntu's signed bootloader; and the bootloader will load either signed or unsigned kernels. If the kernel is signed, it will (as I understand it) leave boot services on so that the kernel can use them, leaving the kernel to turn them off.

  Nonetheless, Ubuntu are still signing their kernel
images, because they want the kernel to be able to play some fancy
tricks for which they need boot-time services.  (I think this is
something to do with making it easy to upload your own keys.) Full EFI
functionality for Xen would include the ability to do this as well.
Yes, because you particularly need access to the EFI variables
from the kernel. Which in turn requires an EFI-enabled kernel.

I'm responding to what you said above: "No. We can't leave [boot] services enabled, and we don't need to." If we want the dom0 kernel to be able to use boot-time services, to enable whatever features Ubuntu &c are using them for, then yes, we will need to leave boot services enabled until dom0 is done using them.

But we should only do that if 1) EFI services are enabled but Xen wasn't signed (i.e,. SecureBoot disabled), or 2) both Xen and dom0 are signed.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.