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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

>>>   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.

Again, no. Boot services are meaningless to the Dom0 kernel
when run under Xen.

Jan


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