Re: EFI + GRUB2 + Xen - Boot Services issues

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On 19.03.2014 17:42, Daniel Kiper wrote:
> 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?
> 
Sorry, I was travelling. I've seen your mail, just didn't respond to it
yet. In nutshell, I think that even in current form it's still useful to
allow payloads to follow 32-bit path as long as they wish to keep it and
still use BS if they need to. I'll fix clobbering problem. As for long
mode entry, it's separate issue, I'm thinking about. There are couple of
problems including where to place the paging tables.
> Daniel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]