[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EFI + GRUB2 + Xen - Boot Services issues
From: |
Daniel Kiper |
Subject: |
Re: EFI + GRUB2 + Xen - Boot Services issues |
Date: |
Wed, 19 Mar 2014 10:42:59 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hey,
On Thu, Mar 06, 2014 at 08:29:25PM +0100, Daniel Kiper wrote:
> Hi,
>
> Vladimir, during my work on final multiboot2 protocol support in Xen on
> EFI platform I stated that GRUB2 patch
> 0df77d793c0436be656f982d96d4edaea4993f96
> (Implement multiboot2 EFI BS specification) may not give access to Boot
> Services as we earlier expected.
>
> In general above mentioned patch gives a way to prevent ExitBootServices()
> call in GRUB2 which is good. However, it looks that this is only part of
> the bigger puzzle. Sadly GRUB2 before jumping into the loaded image switches
> x86 processor mode to 32-bit and disables PG bit in CR0. This is not native
> EFI processor mode. Especially it is very painful on 64-bit EFI
> implementations.
> Even if you can disable ExitBootServices() call later you are not able to call
> Boot Services functions without switching processor mode (this is quite
> simple)
> and recreating page tables (this could be quite complicated). I do not mention
> that system table could be unavailable in 32-bit mode because pointer to it
> is 64-bit and there is no guarantee that it will be placed below 4 GiB.
> However,
> worst thing is that there is no access to ImageHandle which is needed to call
> ExitBootServices(). Hence, I think that if MULTIBOOT2_HEADER_TAG_EFI_BS tag
> is in force at least GRUB2 loader should not touch processor mode on EFI
> platform
> and it should pass pointer to ImageHandle. I am aware that this is very
> intrusive
> change and maybe we should consider reverting
> 0df77d793c0436be656f982d96d4edaea4993f96
> (Implement multiboot2 EFI BS specification) patch from GRUB2 version 2.02 at
> this
> stage of development because there is no guarantee that this change will solve
> all problems with BS. This way we avoid situation in which new feature is
> broken
> from the beginning and we are not able to remove it.
>
> Additionally, I discovered that BS could be overwritten during relocation
> because
> grub_relocator32_boot() is called with last argument (avoid_efi_bootservices)
> set to 0 even if MULTIBOOT2_HEADER_TAG_EFI_BS tag is in force.
Is there anybody out there?
Daniel