[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 15:48, George Dunlap wrote:
On 17/01/13 15:30, Jan Beulich wrote:
On 17.01.13 at 15:32, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 17/01/13 14:15, Jan Beulich wrote:
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.
I think it's slightly different: The shim will only load signed kernels,
but the same kernel can be loaded directly by EFI or the boot
loader to boot non-securely.
As to boot services - in the native case it's always the kernel to
turn them off; in the Xen case it's always Xen.
Again, no. Boot services are meaningless to the Dom0 kernel
when run under Xen.

You are suggesting that Ubuntu only signed their kernels so that someone can use the EFI boot menu to boot shim + Ubuntu kernel?

From what I undertstood from the discussion at the Ubuntu Developer Summit, you are wrong. I may have misunderstood, but it seemed pretty clear to me at the time that:

* Ubuntu, and most of the distros, are trying to avoid having the user do anything through the native EFI menu. This is because the EFI menu will be implemented differently by each different motherboard manufacturer -- making it impossible to provide any kind of reasonable instructions on how to do anything. Furthermore, there's every possibility that the EFI user interface for adding new keys will be quirky, difficult (e.g., type in the key long-hand), or just plain buggy. For that reason, they are still planning on using software bootloaders (like grub) by default, and also planning on providing ways to add keys without using the EFI menu.

Therefore, the plan as I understood it from the EFI session at UDS was as follows:

* Ubuntu has their own shim which will enforce signatures
* Ubuntu plans on having the shim always load a bootloader (with a more full-featured menu which is under Ubuntu's control, as opposed to the EFI menu, which will be different for each platform)
* The bootloader will load either signed or unsigned kernel images
* Ubuntu will still be signing their kernel images, however, because:
* The bootloader will turn off boot services for unsigned images, but will leave boot services on for signed images, so that * The signed kernel binaries can do *other* things with boot services besides booting. I don't know the details of this but I think it had to do with making it possible for users to add their own keys in a consistent manner (rather than using the platform interface, which will be different for each OEM).

I just looked back over a discussion I had with Colin Watson at Ubuntu after UDS. He said:

--- Begin Quote ---

Specifically, we sign kernels in order that we can enter the
kernel without calling ExitBootServices, have the kernel perform some
quirks handling at startup (such as fixing up the framebuffer stride),
and then have the kernel call ExitBootServices itself before doing
anything else interesting.  When Secure Boot is enabled, unsigned
kernels must be entered after calling ExitBootServices, and so cannot
make use of UEFI boot services.

--- End Quote ---

So unless we plan to handle the same quirks in Xen, we're going to need to make it possible for dom0 to do it.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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