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

Re: [Xen-devel] [PATCH] x86/boot: fix MB2 header to require EFI BS



On Tue, Oct 24, 2017 at 10:40:26PM +0100, Andrew Cooper wrote:
> On 24/10/2017 22:11, Daniel Kiper wrote:
> > On Tue, Oct 24, 2017 at 09:22:20PM +0100, Andrew Cooper wrote:
> >> On 24/10/17 21:08, Daniel Kiper wrote:
> >>> On Tue, Oct 24, 2017 at 02:40:41PM -0500, Doug Goldstein wrote:
> >>>> The EFI multiboot2 entry point currently requires EFI BootServices to
> >>>> not have been exited however the header currently tells the boot
> >>>> loader that Xen optionally supports EFI BootServices having been exited.
> >>>> With this change Xen properly advertises that EFI must not be exited
> >>>> allowing the boot loader to report an error that it cannot boot Xen if
> >>>> it is unable to meet its needs.
> >>>>
> >>>> Signed-off-by: Doug Goldstein <cardoe@xxxxxxxxxx>
> >>>> ---
> >>>>
> >>>> This should likely be applied against Xen 4.9 and Xen 4.10 as well as
> >>>> staging. I am trying to get multiboot2 support for iPXE and upstream
> >>>> is concerned that leaving EFI BootServices enabled will not be
> >>>> compatible with their aims to support Secure Boot. So when I build
> >>> Hmmm... What are exact arguments for that? How do they implement e.g.
> >>> chain loading then? What about the shim support?
> >>>
> >>>> my iPXE without support for passing on Boot Services, Xen will be
> >>>> loaded by iPXE but then it will fall down with "ERR: Bootloader
> >>>> shutdown EFI x64 boot services!" implying that this is required. By
> >>>> having Xen expose in its header that its required it allows me to
> >>>> handle the situation gracefully in iPXE.
> >>>>
> >>>> To quote the multiboot2 spec exact:
> >>>>
> >>>> "This tag indicates that payload supports starting without terminating
> >>>> boot services."
> >>>>
> >>>> Unfortunately the spec is a bit vague and how I am reading it is:
> >>>> - no tag = exit boot services in the boot loader
> >>>> - tag present marked optional = boot loader can or cannot exit boot 
> >>>> services
> >>>> - tag present marked required = boot loader cannot exit boot services
> >>> NACK, please take a look at section 3.1.4, Multiboot2 information request
> >>> in Multiboot2 spec. OPTIONAL/REQUIRED has different meaning for the 
> >>> bootloader
> >>> than you think.
> >> The meaning of tag, if understood by Grub, is "don't exit boot services
> >> before passing control".
> > Yep.
> >
> >> The tag is currently marked as optional, which means Grub is free to
> >> ignore it if it doesn't understand it, resulting in EBS being called
> >> before passing control.
> > Yep, but you are forgetting about legacy BIOS platforms with old GRUB2.
> > Right now it is possible to boot Xen via Multiboot2 in such configs.
> > If you set this flag to REQUIRED then old GRUB2 on BIOS platforms will
> > not boot Xen in such cases. If we do not care about that then OK. However,
> > then I would request additional line or so to the commit message saying
> > that such configs are broken deliberately because...
>
> Such older cases wouldn't boot either, because Xen would bail out saying
> "I didn't retain BS like I need".

Nope, you should remember that legacy entry point (__start) will be used then.

> >> Xen cannot cope with with EBS having been called, so must not be passed
> >> control under those circumstances.
> > Even with REQUIRED flag there is no guarantee that booloader will do
> > what Xen asks. So, it has to check the boot services presence anyway.
> > And it does.
>
> Indeed, and rightly so.
>
> The difference between Grub bailing out with an error, and Xen bailing
> out with an error, is that one still leaves you at a grub prompt, while
> one locks your system up until you remove some electrons from it.
>
> Setting the REQUIRED flag appears to be strictly better behaviour from
> the users point of view.

Yep, I put a solution proposal for that issue in other email.

Daniel

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

 


Rackspace

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