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

Re: [Xen-devel] EFI + GRUB2 + Xen - Boot Services issues



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

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


 


Rackspace

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