Discussion:
[PATCH 2/2] mkimage: arm64-efi: Align first section to page
Alexander Graf
2018-11-28 14:31:07 UTC
Permalink
I encountered a broken edk2 implementation in the wild (HP Envy x2)
which fails to load PE binaries that have a non-page-aligned first
section (read: header is < 4k).

Work around this by just aligning the text start to page granule on the
arm64-efi target.

With this patch applied, I can successfully run grub on my HP Envy x2
system.

Signed-off-by: Alexander Graf <***@suse.de>
---
util/mkimage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/util/mkimage.c b/util/mkimage.c
index 05333a76a..bfdb0328a 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -605,7 +605,8 @@ static const struct grub_install_image_target_desc image_targets[] =
.decompressor_uncompressed_size = TARGET_NO_FIELD,
.decompressor_uncompressed_addr = TARGET_NO_FIELD,
.section_align = GRUB_PE32_SECTION_ALIGNMENT,
- .vaddr_offset = EFI64_HEADER_SIZE,
+ /* Needed for some broken edk2 implementations */
+ .vaddr_offset = 4096,
.pe_target = GRUB_PE32_MACHINE_ARM64,
.elf_target = EM_AARCH64,
},
--
2.19.0
Alexander Graf
2018-11-28 14:31:06 UTC
Permalink
For EFI images, we always have the following layout:

[PE header]
[padding]
[first section (which also is the entry point)]

Currently there are 2 places where we define how big header+padding are:
in the .vaddr_offset member of our target image definition struct as well
as in code in grub_install_generate_image().

Remove the latter, so that we only have a single place to modify if we
need to change the padding.

Signed-off-by: Alexander Graf <***@suse.de>
---
util/mkimage.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/util/mkimage.c b/util/mkimage.c
index b2f43fea6..05333a76a 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -1206,10 +1206,7 @@ grub_install_generate_image (const char *dir, const char *prefix,
int header_size;
int reloc_addr;

- if (image_target->voidp_sizeof == 4)
- header_size = EFI32_HEADER_SIZE;
- else
- header_size = EFI64_HEADER_SIZE;
+ header_size = image_target->vaddr_offset;

reloc_addr = ALIGN_UP (header_size + core_size,
image_target->section_align);
--
2.19.0
Leif Lindholm
2018-11-29 09:02:33 UTC
Permalink
Hi Alex,
I got a new toy this week: An HP Envy X2 system. This is one of those shiny
new Qualcomm Snapdragon based Windows tablet/notebook hybrid things.
While running Windows on those is actually not a terribly bad experience now
that WSL is out, I would like to see Linux run on those as well in the future.
Unfortunately as far as I'm aware so far nobody was able to run self built
binaries on the built-in UEFI version.
Turns out, it's a problem with aligning the start of the header to 4k. Once
we do that, binaries can be loaded just fine and run.
Nice job!
So to maintain compatibility with that device, this patch set just bumps the
header alignment to 4K always on arm64-efi. This shouldn't hurt too much for
not affected targets and allows us to have a single grub binary that can then
chain load Linux properly.
While I really appreciate this work, let's start by trying to get HP
to fix their device. Shouldn't be too hard to get a firmware update
rolled out.

Then we might want to add a test to now-opensource UEFI SCT :)

I'm going to be a bit busy today, but will put together a simpler
proof-of-concept (i.e. edk2 HelloWorld) tomorrow and test on my own
Envy X2, and send it to HP.

Regards,

Leif
Alex
mkimage: Simplify header size logic
mkimage: arm64-efi: Align first section to page
util/mkimage.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--
2.19.0
Jon Masters
2018-11-29 10:01:08 UTC
Permalink
I got a new toy this week: An HP Envy X2 system. This is one of those shiny
new Qualcomm Snapdragon based Windows tablet/notebook hybrid things.
Cool! I've got one too, and hadn't poked since we looked a while back,
so it'll be great to have a motivation to look at this again soon!
While running Windows on those is actually not a terribly bad experience now
that WSL is out, I would like to see Linux run on those as well in the future.
Unfortunately as far as I'm aware so far nobody was able to run self built
binaries on the built-in UEFI version.
Turns out, it's a problem with aligning the start of the header to 4k. Once
we do that, binaries can be loaded just fine and run.
So to maintain compatibility with that device, this patch set just bumps the
header alignment to 4K always on arm64-efi. This shouldn't hurt too much for
not affected targets and allows us to have a single grub binary that can then
chain load Linux properly.
This is awesome work. Obvious when you know it, but glad you did the
hard work to figure that out. I'm thinking Leif is right, we should try
to get HP to fix their firmware, especially since we know what is
broken. If Leif ends up needing any help prodding HP, we can try to
figure out who to talk to, or ask some other friends for assistance.

I owe you another tea ;)

Jon.
--
Computer Architect | Sent with my Fedora powered laptop
Alexander Graf
2018-11-29 17:19:14 UTC
Permalink
Post by Jon Masters
I got a new toy this week: An HP Envy X2 system. This is one of those shiny
new Qualcomm Snapdragon based Windows tablet/notebook hybrid things.
Cool! I've got one too, and hadn't poked since we looked a while back,
so it'll be great to have a motivation to look at this again soon!
While running Windows on those is actually not a terribly bad experience now
that WSL is out, I would like to see Linux run on those as well in the future.
Unfortunately as far as I'm aware so far nobody was able to run self built
binaries on the built-in UEFI version.
Turns out, it's a problem with aligning the start of the header to 4k. Once
we do that, binaries can be loaded just fine and run.
So to maintain compatibility with that device, this patch set just bumps the
header alignment to 4K always on arm64-efi. This shouldn't hurt too much for
not affected targets and allows us to have a single grub binary that can then
chain load Linux properly.
This is awesome work. Obvious when you know it, but glad you did the
hard work to figure that out. I'm thinking Leif is right, we should try
to get HP to fix their firmware, especially since we know what is
broken. If Leif ends up needing any help prodding HP, we can try to
figure out who to talk to, or ask some other friends for assistance.
If you manage to convince them (and MS to roll it out automatically),
that would obviously be the better alternative. They seem to have
capsule updates on there, so I assume there are channels in place.

While you're at it, could you also poke them to up their FADT to 5.1?
The fact they're on 5.0 is the main reason Linux doesn't boot.
Post by Jon Masters
I owe you another tea ;)
Oh, memories :). I'll tell you what happened after that tea next time we
bump into each other ;). Maybe for that I'll need something stronger though.


Cheers,

Alex

Loading...