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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.01.13 at 16:48, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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?

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

> 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

My understanding was that the fundamentals of the shim are
going to be shared.

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

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

Adding keys, according to the vague description I had been
given, is an indirect operation - the kernel tells the shim to
add a key during next boot. And there was some extra step
to be done for the first time (installation) boot.

> Therefore, if we want Ubuntu+Xen to have the same functionality as 
> Ubuntu w/o Xen, then:
> * When the dom0 kernel is signed, Xen will need to leave boot-time 
> services enabled

Once again - this is a no-go. All boot services memory got
reclaimed by the time Dom0 gets launched, so there's no way
for Dom0 to access boot services. Even Xen itself cannot
arbitrarily use them - they get turned of near the end of
efi_start(). Anything else is conceptually wrong, even if it
might be possible to be made work.

> * dom0 will need to have hooks so that it can access boot-time services 
> and then disable them.

If there's any runtime service they need access to and we don't,
they'd need to contribute patches. For our model, all pieces
should be in place (albeit someone is yet to try this all out).

And to be clear - unless someone manages to eliminate the
"conceptually wrong" argument above, I'm intending to veto
any changes that violate the model set by the specification.

Jan


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