All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Doug Goldstein <cardoe@cardoe.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/boot: fix MB2 header to require EFI BS
Date: Tue, 24 Oct 2017 23:11:54 +0200	[thread overview]
Message-ID: <20171024211154.GQ7593@olila.local.net-space.pl> (raw)
In-Reply-To: <b55a34b8-04ed-85e5-ad2a-062bfe7c3245@citrix.com>

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@cardoe.com>
> >> ---
> >>
> >> 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...

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

Daniel

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

  parent reply	other threads:[~2017-10-24 21:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-24 19:40 [PATCH] x86/boot: fix MB2 header to require EFI BS Doug Goldstein
2017-10-24 20:08 ` Daniel Kiper
2017-10-24 20:22   ` Andrew Cooper
2017-10-24 20:49     ` Doug Goldstein
2017-10-24 22:16       ` Daniel Kiper
2017-10-24 21:11     ` Daniel Kiper [this message]
2017-10-24 21:40       ` Andrew Cooper
2017-10-24 22:20         ` Daniel Kiper
2017-10-25 13:52           ` Doug Goldstein
2017-10-24 20:28   ` Doug Goldstein
2017-10-24 21:40     ` Daniel Kiper
2017-10-24 20:34   ` Doug Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171024211154.GQ7593@olila.local.net-space.pl \
    --to=daniel.kiper@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.