* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
@ 2019-01-19 10:21 Heinrich Schuchardt
2019-01-19 11:55 ` Heinrich Schuchardt
0 siblings, 1 reply; 6+ messages in thread
From: Heinrich Schuchardt @ 2019-01-19 10:21 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
2019-01-19 10:21 [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file Heinrich Schuchardt
@ 2019-01-19 11:55 ` Heinrich Schuchardt
2019-01-19 16:40 ` Heinrich Schuchardt
2019-01-21 15:44 ` Alexander Graf
0 siblings, 2 replies; 6+ messages in thread
From: Heinrich Schuchardt @ 2019-01-19 11:55 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
2019-01-19 11:55 ` Heinrich Schuchardt
@ 2019-01-19 16:40 ` Heinrich Schuchardt
2019-01-19 17:54 ` Alexander Graf
2019-01-21 15:44 ` Alexander Graf
1 sibling, 1 reply; 6+ messages in thread
From: Heinrich Schuchardt @ 2019-01-19 16:40 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
2019-01-19 16:40 ` Heinrich Schuchardt
@ 2019-01-19 17:54 ` Alexander Graf
2019-01-19 18:27 ` Heinrich Schuchardt
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Graf @ 2019-01-19 17:54 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
2019-01-19 17:54 ` Alexander Graf
@ 2019-01-19 18:27 ` Heinrich Schuchardt
0 siblings, 0 replies; 6+ messages in thread
From: Heinrich Schuchardt @ 2019-01-19 18:27 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file
2019-01-19 11:55 ` Heinrich Schuchardt
2019-01-19 16:40 ` Heinrich Schuchardt
@ 2019-01-21 15:44 ` Alexander Graf
1 sibling, 0 replies; 6+ messages in thread
From: Alexander Graf @ 2019-01-21 15:44 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-21 15:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-19 10:21 [U-Boot] [BUG ] efiloader: incorrect creation of *.efi file Heinrich Schuchardt
2019-01-19 11:55 ` Heinrich Schuchardt
2019-01-19 16:40 ` Heinrich Schuchardt
2019-01-19 17:54 ` Alexander Graf
2019-01-19 18:27 ` Heinrich Schuchardt
2019-01-21 15:44 ` Alexander Graf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.