EFI + GRUB2 + Xen - Boot Services issues

EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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.

Daniel

EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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.

Daniel

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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.

Ping?

Daniel

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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.

Ping?

Daniel

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

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

Re: EFI + GRUB2 + Xen - Boot Services issues

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: EFI + GRUB2 + Xen - Boot Services issues

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

Hi,

On Wed, Mar 19, 2014 at 08:58:43PM +0800, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 19.03.2014 17:42, Daniel Kiper wrote:

[...]

> > Is there anybody out there?
> >
> Sorry, I was travelling. I've seen your mail, just didn't respond to it

No problem.

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

Great... I could wait a bit because I am working on EFI and Xen Linux
Kernel patches right now. Drop me a line if you need my help.

Daniel

Re: EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper]

Hi,

On Wed, Mar 19, 2014 at 08:58:43PM +0800, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 19.03.2014 17:42, Daniel Kiper wrote:

[...]

> > Is there anybody out there?
> >
> Sorry, I was travelling. I've seen your mail, just didn't respond to it

No problem.

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

Great... I could wait a bit because I am working on EFI and Xen Linux
Kernel patches right now. Drop me a line if you need my help.

Daniel

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