Re: Xen 4.3 development update, and stock-taking

[George Dunlap <george.dunlap@eu.citrix.com>]

On 17/01/13 16:14, Jan Beulich wrote:
>>>> On 17.01.13 at 16:48, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> You are suggesting that Ubuntu only signed their kernels so that someone
>> can use the EFI boot menu to boot shim + Ubuntu kernel?
> Yes, what else?

Well, the whole reason we had this discussion is that my understanding 
of how EFI secure boot is going to work and your understanding of how 
it's going to work were different in important ways.  Given that, how 
should I know what else you might mean? Better to say it explicitly to 
make sure, rather than arguing for another 10 e-mails based on a 
misunderstanding. :-)

>>   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.
> That all sounds very close to what our folks are intending to do,
> except that we're not planning on enforcing the use of a boot
> loader (or if so, Xen would get chain-loaded rather than started
> through multiboot).

I don't think Ubuntu is planning on *enforcing* it; just that Ubuntu 
(and other distros) will *prefer* it.

>> * 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
> Again - Linux expects to be turning off boot services itself. So
> there's no question of the boot loader doing so.
>
> There are certain other restrictions to what a not securely boot
> can do, of course.

How does this in any way disagree with the sentence to which you're 
responding?

Case 1: Signed linux image.  Linux expects to turn boot services off -> 
bootloader doesn't.
Case 2: Unsigned linux image.  "Certain other restrictions" -> 
bootloader turns boot services off.

They seem 100% compatible.

  -George