[U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
Best regards
Heinrich
helloworld.efi: 00000140 00 00 00 00 20 00 50 E0 FD 7B BE A9 FD 03 00 91 00000150 E0 07 01 A9 60 F5 FF 10 01 00 00 90 21 C0 19 91 00000160 A7 00 00 94 60 00 00 B5 E0 07 41 A9 0F 00 00 94 00000170 FD 7B C2 A8 C0 03 5F D6 >03 00 80 D2< 02 68 63 38 00000180 24 68 63 38 5F 00 04 6B 60 00 00 54 40 00 04 4B 00000190 C0 03 5F D6 63 04 00 91 7F 40 00 F1 01 FF FF 54 000001A0 00 00 80 52 FB FF FF 17 >FD 7B B7 A9< 82 01 80 D2 000001B0 FD 03 00 91 F3 53 01 A9 F3 03 02 91 F4 03 01 AA 000001C0 F5 5B 02 A9 F7 63 03 A9 F9 6B 04 A9 FB 73 05 A9
lib/efi_loader/helloworld.o: file format elf64-littleaarch64 Disassembly of section .text:
0000000000000000 <hw_memcmp.constprop.0>: 0: d2800003 mov x3, #0x0 // #0 4: 38636802 ldrb w2, [x0, x3] 8: 38636824 ldrb w4, [x1, x3] c: 6b04005f cmp w2, w4 10: 54000060 b.eq 1c <hw_memcmp.constprop.0+0x1c> // b.none 14: 4b040040 sub w0, w2, w4 18: d65f03c0 ret 1c: 91000463 add x3, x3, #0x1 20: f100407f cmp x3, #0x10 24: 54ffff01 b.ne 4 <hw_memcmp.constprop.0+0x4> // b.any 28: 52800000 mov w0, #0x0 // #0 2c: 17fffffb b 18 <hw_memcmp.constprop.0+0x18>
0000000000000030 <efi_main>: 30: a9b77bfd stp x29, x30, [sp, #-144]! 34: d2800182 mov x2, #0xc // #12 38: 910003fd mov x29, sp 3c: a90153f3 stp x19, x20, [sp, #16] 40: 910203f3 add x19, sp, #0x80 44: aa0103f4 mov x20, x1 48: a9025bf5 stp x21, x22, [sp, #32] 4c: a90363f7 stp x23, x24, [sp, #48] 50: a9046bf9 stp x25, x26, [sp, #64] 54: a90573fb stp x27, x28, [sp, #80] 58: fd0033e8 str d8, [sp, #96] 5c: 9e670008 fmov d8, x0 60: f940203b ldr x27, [x1, #64] 64: aa1303e0 mov x0, x19 68: f940303a ldr x26, [x1, #96] 6c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 70: 91000021 add x1, x1, #0x0 74: 94000000 bl 0 <memcpy> 78: f9400762 ldr x2, [x27, #8] 7c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 80: aa1b03e0 mov x0, x27 84: 91000021 add x1, x1, #0x0 88: d63f0040 blr x2 8c: b9400a80 ldr w0, [x20, #8] 90: 52800004 mov w4, #0x0 // #0
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote:
Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
Best regards
Heinrich
On 1/19/19 12:55 PM, Heinrich Schuchardt wrote:
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote:
Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
Best regards
Heinrich
Though I still do not understand why we call relocation twice the real bug seems to stem form a call to a non-existent memcpy() function.
See address 0x74 of the disassembly.
https://gcc.gnu.org/onlinedocs/gcc/Standards.html teaches: "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp."
struct efi_simple_text_output_protocol *con_out = systable->con_out; 60: f940203b ldr x27, [x1, #64] u16 rev[] = L"0.0.0"; 64: aa1303e0 mov x0, x19 struct efi_boot_services *boottime = systable->boottime; 68: f940303a ldr x26, [x1, #96] u16 rev[] = L"0.0.0"; 6c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 70: 91000021 add x1, x1, #0x0 74: 94000000 bl 0 <memcpy>
/* UEFI requires CR LF */ con_out->output_string(con_out, L"Hello, world!\r\n"); 78: f9400762 ldr x2, [x27, #8] 7c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 80: aa1b03e0 mov x0, x27 84: 91000021 add x1, x1, #0x0 88: d63f0040 blr x2
Regards
Heinrich
Am 19.01.2019 um 17:40 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
On 1/19/19 12:55 PM, Heinrich Schuchardt wrote:
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote: Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
Best regards
Heinrich
Though I still do not understand why we call relocation twice the real bug seems to stem form a call to a non-existent memcpy() function.
See address 0x74 of the disassembly.
Ah, yes. You must not use -Os for the efi binary, otherwise it pulls it back in. I guess I should've put a comment there...
Alex
https://gcc.gnu.org/onlinedocs/gcc/Standards.html teaches: "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp."
struct efi_simple_text_output_protocol *con_out = systable->con_out;60: f940203b ldr x27, [x1, #64] u16 rev[] = L"0.0.0"; 64: aa1303e0 mov x0, x19 struct efi_boot_services *boottime = systable->boottime; 68: f940303a ldr x26, [x1, #96] u16 rev[] = L"0.0.0"; 6c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 70: 91000021 add x1, x1, #0x0 74: 94000000 bl 0 <memcpy>
/* UEFI requires CR LF */ con_out->output_string(con_out, L"Hello, world!\r\n");78: f9400762 ldr x2, [x27, #8] 7c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 80: aa1b03e0 mov x0, x27 84: 91000021 add x1, x1, #0x0 88: d63f0040 blr x2
Regards
Heinrich
On 1/19/19 6:54 PM, Alexander Graf wrote:
Am 19.01.2019 um 17:40 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
On 1/19/19 12:55 PM, Heinrich Schuchardt wrote:
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote: Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
Best regards
Heinrich
Though I still do not understand why we call relocation twice the real bug seems to stem form a call to a non-existent memcpy() function.
See address 0x74 of the disassembly.
Ah, yes. You must not use -Os for the efi binary, otherwise it pulls it back in. I guess I should've put a comment there...
Alex
As GCC is explicitly requiring that a freestanding binary has memcpy this is gone to break some day again. I have created a patch series that adds the missing functions to all *.efi binaries.
It is currently running on Travis CI.
Could you, please, comment on the question of duplicate relocation.
Best regards
Heinrich
On 01/19/2019 12:55 PM, Heinrich Schuchardt wrote:
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote:
Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
IIRC we don't generate PE relocations from ELF relocations. Instead, we bundle ELF relocations into its own section inside the target binary and then relocate ourselves.
So in the binary you're examining, there should be no pe relocations.
Alex
participants (2)
-
Alexander Graf -
Heinrich Schuchardt