Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
Hi Heinrich, On Thu, Oct 25, 2018 at 2:25 PM Heinrich Schuchardt wrote: > > On 10/24/2018 11:48 PM, Heinrich Schuchardt wrote: > > On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: > >>> Hello Hannes, > >>> > >>> thanks for reporting the problem. > >>> > >>> There are two possible reasons: > >>> > >>> a) The build process introduces relocations of the reported type. > >>> b) The relocation records are overwritten before relocation. This > >>> happens if you update uninitialized globals. > >>> > >>> To analyze your problem further, please, provide instructions for > >>> building your version of U-Boot (repository, commit, config). That will > >>> allow to check for a). > >>> > >>> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would > >>> allow to analyze case b). Are you able to reproduce the problem with > >>> QEMU? > >>> > >>> Best regards > >>> > >>> Heinrich > >>> > >> Hello Heinrich, > >> > >> thanks for this input. > >> The "trouble" occurs also with QEMU, have a look to console output below. > >> > >> Maybe you can investigate on this, I've pushed the branch to my github > >> account: > >> > >> https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb > >> config is "brpp065mb" > >> > >> please let me know if i can help. > >> > >> cheers, > >> Hannes > > > > And running qemu-x86_defonfig results in > > do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, > > offset = 0xfff00091 > > > > So the problem is not restricted to your board. > > > > I have had a first look at the relocations actually present in the > > u-boot ELF file. > > > > Your repo: > > make brpp065mb_defconfig > > make > > objdump -r u-boot | cut -c10-20 | sort | uniq > > > > R_386_32 > > R_386_NONE > > R_386_PC32 > > > > u-boot master: > > make qemu-x86_defconfig > > make > > objdump -r u-boot | cut -c10-20 | sort | uniq > > > > R_386_16 > > R_386_32 > > R_386_NONE > > R_386_PC16 > > R_386_PC32 > > > > The current relocation code only supports a single relocation type > > (R_386_RELATIVE). > > > > What I still do not understand is why most of the relocations that we > > actually see inside U-Boot are of type R_386_RELATIVE). So where are the > > relocations transformed on the way from u-boot to u-boot.bin? > > > > The following command drops some sections and creates an image without > > any relocation information: > > > > objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot > > u-boot-nodtb.bin > > > > But where are the R_386_RELATIVEs created? > > > > @Bin: do you have an understanding of how this works? > > > > Best regards > > > > Heinrich > > > > I delved a bit deeper into the biaries: > > For qemu-x86_defconfig objcopy eliminates all R_386_PC32 relocations > except the last one when creating u-boot-nofdt.bin. > > Hannes could you please, send me your u-boot-nodtb.bin, u-boot, and > u-boot.map. It seems my build system is not creating the relocation > record at 0x287 that was reported by you. > > Here are the file details for qemu-x86_defconfig: > > > Error message: > > do_elf_reloc_fixups32: > unsupported relocation type 0x2 at fff84e78, offset = 0xfff00091 > > > objdump -drS u-boot > > callcar_uninit > fff00090: e8 fc ff ff ff > call fff00091 > fff00091: R_386_PC32car_uninit > 1: > /* Re-enter U-Boot by calling board_init_f_r() */ > callboard_init_f_r > fff00095: e8 a0 09 01 00 > call fff10a3a > fff00096: R_386_PC32board_init_f_r > > > Memory dump via gdb: > > 0xfff84e60: 0xfff73044 0x0008 0xfff73048 0x0008 > 0xfff84e70: 0xfff7304c 0x0008 0xfff00091 0x0102 > 0xfff84e80: 0xedfe0dd0 0x0b07 0x3800 0xd805 > 0xfff84e90: 0x2800 0x1100 0x1000 0x > > > u-boot.map > > .rel.data.test_commands > 0xfff84e00 0x60 arch/x86/cpu/start.o > .rel.u_boot_list_2_cmd_2_dm > 0xfff84e60 0x20 arch/x86/cpu/start.o > 0xfff84e80__rel_dyn_end = . > 0xfff84e80. = ALIGN (0x4) > 0xfff84e80_end = . > > > u-boot-nodtb.bin: > > 00084E60 44 30 F7 FF 08 00 00 00 48 30 F7 FF 08 00 00 00 > 00084E70 4C 30 F7 FF 08 00 00 00 91 00 F0 FF 02 01 00 00 > --- u-boot-nodtb.bin --0x84E80/0x84E80 > > > The same trailing R_386_PC32 I could see with Hannes example: > > 0004CFD8 10 32 04 02 08 00 00 00 18 32 04 02 08 00 00 00 > 0004CFE8 24 32 04 02 08 00 00 00 28 32 04 02 08 00 00 00 > 0004CFF8 2C 32 04 02 08 00 00 00 91 00 00 02 02 01 00 00 > --- u-boot-nodtb.bin --0x4D008/0x4D008--- There is a bug in the start.S. I will send a patch soon. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
Hi Heinrich, On Thu, Oct 25, 2018 at 5:48 AM Heinrich Schuchardt wrote: > > On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: > >> Hello Hannes, > >> > >> thanks for reporting the problem. > >> > >> There are two possible reasons: > >> > >> a) The build process introduces relocations of the reported type. > >> b) The relocation records are overwritten before relocation. This > >> happens if you update uninitialized globals. > >> > >> To analyze your problem further, please, provide instructions for > >> building your version of U-Boot (repository, commit, config). That will > >> allow to check for a). > >> > >> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would > >> allow to analyze case b). Are you able to reproduce the problem with > >> QEMU? > >> > >> Best regards > >> > >> Heinrich > >> > > Hello Heinrich, > > > > thanks for this input. > > The "trouble" occurs also with QEMU, have a look to console output below. > > > > Maybe you can investigate on this, I've pushed the branch to my github > > account: > > > > https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb > > config is "brpp065mb" > > > > please let me know if i can help. > > > > cheers, > > Hannes > > And running qemu-x86_defonfig results in > do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, > offset = 0xfff00091 > > So the problem is not restricted to your board. > > I have had a first look at the relocations actually present in the > u-boot ELF file. > > Your repo: > make brpp065mb_defconfig > make > objdump -r u-boot | cut -c10-20 | sort | uniq > > R_386_32 > R_386_NONE > R_386_PC32 > > u-boot master: > make qemu-x86_defconfig > make > objdump -r u-boot | cut -c10-20 | sort | uniq > > R_386_16 > R_386_32 > R_386_NONE > R_386_PC16 > R_386_PC32 > > The current relocation code only supports a single relocation type > (R_386_RELATIVE). > > What I still do not understand is why most of the relocations that we > actually see inside U-Boot are of type R_386_RELATIVE). So where are the > relocations transformed on the way from u-boot to u-boot.bin? > > The following command drops some sections and creates an image without > any relocation information: > No, the following command only remove the 16-bit codes from the u-boot image. Other sections are untouched. > objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot > u-boot-nodtb.bin > > But where are the R_386_RELATIVEs created? > It's in the u-boot.bin image. We don't touch it during the build process. > @Bin: do you have an understanding of how this works? > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/24/2018 11:48 PM, Heinrich Schuchardt wrote: > On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: >>> Hello Hannes, >>> >>> thanks for reporting the problem. >>> >>> There are two possible reasons: >>> >>> a) The build process introduces relocations of the reported type. >>> b) The relocation records are overwritten before relocation. This >>> happens if you update uninitialized globals. >>> >>> To analyze your problem further, please, provide instructions for >>> building your version of U-Boot (repository, commit, config). That will >>> allow to check for a). >>> >>> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would >>> allow to analyze case b). Are you able to reproduce the problem with >>> QEMU? >>> >>> Best regards >>> >>> Heinrich >>> >> Hello Heinrich, >> >> thanks for this input. >> The "trouble" occurs also with QEMU, have a look to console output below. >> >> Maybe you can investigate on this, I've pushed the branch to my github >> account: >> >> https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb >> config is "brpp065mb" >> >> please let me know if i can help. >> >> cheers, >> Hannes > > And running qemu-x86_defonfig results in > do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, > offset = 0xfff00091 > > So the problem is not restricted to your board. > > I have had a first look at the relocations actually present in the > u-boot ELF file. > > Your repo: > make brpp065mb_defconfig > make > objdump -r u-boot | cut -c10-20 | sort | uniq > > R_386_32 > R_386_NONE > R_386_PC32 > > u-boot master: > make qemu-x86_defconfig > make > objdump -r u-boot | cut -c10-20 | sort | uniq > > R_386_16 > R_386_32 > R_386_NONE > R_386_PC16 > R_386_PC32 > > The current relocation code only supports a single relocation type > (R_386_RELATIVE). > > What I still do not understand is why most of the relocations that we > actually see inside U-Boot are of type R_386_RELATIVE). So where are the > relocations transformed on the way from u-boot to u-boot.bin? > > The following command drops some sections and creates an image without > any relocation information: > > objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot > u-boot-nodtb.bin > > But where are the R_386_RELATIVEs created? > > @Bin: do you have an understanding of how this works? > > Best regards > > Heinrich > I delved a bit deeper into the biaries: For qemu-x86_defconfig objcopy eliminates all R_386_PC32 relocations except the last one when creating u-boot-nofdt.bin. Hannes could you please, send me your u-boot-nodtb.bin, u-boot, and u-boot.map. It seems my build system is not creating the relocation record at 0x287 that was reported by you. Here are the file details for qemu-x86_defconfig: Error message: do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e78, offset = 0xfff00091 objdump -drS u-boot callcar_uninit fff00090: e8 fc ff ff ff call fff00091 fff00091: R_386_PC32car_uninit 1: /* Re-enter U-Boot by calling board_init_f_r() */ callboard_init_f_r fff00095: e8 a0 09 01 00 call fff10a3a fff00096: R_386_PC32board_init_f_r Memory dump via gdb: 0xfff84e60: 0xfff73044 0x0008 0xfff73048 0x0008 0xfff84e70: 0xfff7304c 0x0008 0xfff00091 0x0102 0xfff84e80: 0xedfe0dd0 0x0b07 0x3800 0xd805 0xfff84e90: 0x2800 0x1100 0x1000 0x u-boot.map .rel.data.test_commands 0xfff84e00 0x60 arch/x86/cpu/start.o .rel.u_boot_list_2_cmd_2_dm 0xfff84e60 0x20 arch/x86/cpu/start.o 0xfff84e80__rel_dyn_end = . 0xfff84e80. = ALIGN (0x4) 0xfff84e80_end = . u-boot-nodtb.bin: 00084E60 44 30 F7 FF 08 00 00 00 48 30 F7 FF 08 00 00 00 00084E70 4C 30 F7 FF 08 00 00 00 91 00 F0 FF 02 01 00 00 --- u-boot-nodtb.bin --0x84E80/0x84E80 The same trailing R_386_PC32 I could see with Hannes example: 0004CFD8 10 32 04 02 08 00 00 00 18 32 04 02 08 00 00 00 0004CFE8 24 32 04 02 08 00 00 00 28 32 04 02 08 00 00 00 0004CFF8 2C 32 04 02 08 00 00 00 91 00 00 02 02 01 00 00 --- u-boot-nodtb.bin --0x4D008/0x4D008--- Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: >> Hello Hannes, >> >> thanks for reporting the problem. >> >> There are two possible reasons: >> >> a) The build process introduces relocations of the reported type. >> b) The relocation records are overwritten before relocation. This >> happens if you update uninitialized globals. >> >> To analyze your problem further, please, provide instructions for >> building your version of U-Boot (repository, commit, config). That will >> allow to check for a). >> >> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would >> allow to analyze case b). Are you able to reproduce the problem with >> QEMU? >> >> Best regards >> >> Heinrich >> > Hello Heinrich, > > thanks for this input. > The "trouble" occurs also with QEMU, have a look to console output below. > > Maybe you can investigate on this, I've pushed the branch to my github > account: > > https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb > config is "brpp065mb" > > please let me know if i can help. > > cheers, > Hannes And running qemu-x86_defonfig results in do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, offset = 0xfff00091 So the problem is not restricted to your board. I have had a first look at the relocations actually present in the u-boot ELF file. Your repo: make brpp065mb_defconfig make objdump -r u-boot | cut -c10-20 | sort | uniq R_386_32 R_386_NONE R_386_PC32 u-boot master: make qemu-x86_defconfig make objdump -r u-boot | cut -c10-20 | sort | uniq R_386_16 R_386_32 R_386_NONE R_386_PC16 R_386_PC32 The current relocation code only supports a single relocation type (R_386_RELATIVE). What I still do not understand is why most of the relocations that we actually see inside U-Boot are of type R_386_RELATIVE). So where are the relocations transformed on the way from u-boot to u-boot.bin? The following command drops some sections and creates an image without any relocation information: objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot-nodtb.bin But where are the R_386_RELATIVEs created? @Bin: do you have an understanding of how this works? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/24/2018 02:35 AM, Heinrich Schuchardt wrote:
On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or
ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt
---
arch/x86/lib/relocate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..01e619d20b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int
text_base, uintptr_t size,
Elf64_Addr *offset_ptr_ram;
do {
+ unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+
+ if (type != R_X86_64_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%llx "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%llx\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int
text_base, uintptr_t size,
Elf32_Addr *offset_ptr_ram;
do {
+ unsigned int type = ELF32_R_TYPE(re_src->r_info);
+
+ if (type != R_386_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%x "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%x\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich,
i just merged recent u-boot master into my devbranch and ran it on my
board:
--
U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h
DRAM: 119.6 MiB
do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0,
offset = 0x287
do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8,
offset = 0x291
Bus 0: OK
---
now i get such relocation warnings, can you help me in this how to deal
with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers,
Hannes
Hello Hannes,
thanks for reporting the problem.
There are two possible reasons:
a) The build process introduces relocations of the reported type.
b) The relocation records are overwritten before relocation. This
happens if you update uninitialized globals.
To analyze your problem further, please, provide instructions for
building your version of U-Boot (repository, commit, config). That will
allow to check for a).
Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would
allow to analyze case b). Are you able to reproduce the problem with QEMU?
Best regards
Heinrich
Hello Heinrich,
thanks for this input.
The "trouble" occurs also with QEMU, have a look to console output below.
Maybe you can investigate on this, I've pushed the branch to my github
account:
https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb
config is "brpp065mb"
please let me know if i can help.
cheers,
Hannes
schmelzerh@scm-ws10 /tmp $ qemu-system-i386 -bios coreboot.rom -serial stdio
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 romstage
starting...
CBMEM:
IMD: root @ 07fff000 254 entries.
IMD: root @ 07ffec00 62 entries.
CBFS: 'Master Header Locator' located CBFS at [200:3ffc0)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 3d40 size ad33
Decompressing stage fallback/ramstage @ 0x07fbcfc0 (128696 bytes)
Loading module at 07fbd000 with entry 07fbd000. filesize: 0x15810
memsize: 0x1f678
Processing 1261 relocs. Offset value of 0x071bd000
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 ramstage
starting...
Enumerating buses...
CPU_CLUSTER: 0 enabled
DOMAIN: enabled
QEMU: firmware config interface detected
QEMU: max_cpus is 1
CPU: APIC: 00 enabled
scan_bus: scanning of bus CPU_CLUSTER: 0 took 0 usecs
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/1237] enabled
PCI: 00:01.0 [8086/7000] enabled
PCI: 00:01.1 [8086/7010] enabled
PCI: 00:01.3 [8086/7113] enabled
PCI: 00:02.0 [1234/] enabled
PCI: 00:03.0 [8086/100e] enabled
scan_bus: scanning of bus PCI: 00:01.0 took 0 usecs
scan_bus: scanning of bus PCI: 00:01.3 took 0 usecs
scan_bus: scanning of bus DOMAIN: took 0 usecs
scan_bus: scanning of bus Root Device took 0 usecs
done
found VGA at PCI: 00:02.0
Setting up VGA for PCI: 00:02.0
Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN:
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
QEMU: 11 files in fw_cfg
QEMU: etc/boot-fail-wait [size=4]
QEMU:
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
>
> On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
>> Currently we support only relocations of type ELF64_R_TYPE or
>> ELF32_R_TYPE.
>> We should be warned if other relocation types appear in the relocation
>> sections.
>>
>> This type of message has helped to identify code overwriting a relocation
>> section before relocation and incorrect parsing of relocation tables.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> arch/x86/lib/relocate.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
>> index ed10755d9c..01e619d20b 100644
>> --- a/arch/x86/lib/relocate.c
>> +++ b/arch/x86/lib/relocate.c
>> @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int
>> text_base, uintptr_t size,
>> Elf64_Addr *offset_ptr_ram;
>> do {
>> + unsigned long long type = ELF64_R_TYPE(re_src->r_info);
>> +
>> + if (type != R_X86_64_RELATIVE) {
>> + printf("%s: unsupported relocation type 0x%llx "
>> + "at %p, ",__func__, type, re_src);
>> + printf("offset = 0x%llx\n", re_src->r_offset);
>> + continue;
>> + }
>> +
>> /* Get the location from the relocation entry */
>> offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
>> @@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int
>> text_base, uintptr_t size,
>> Elf32_Addr *offset_ptr_ram;
>> do {
>> + unsigned int type = ELF32_R_TYPE(re_src->r_info);
>> +
>> + if (type != R_386_RELATIVE) {
>> + printf("%s: unsupported relocation type 0x%x "
>> + "at %p, ",__func__, type, re_src);
>> + printf("offset = 0x%x\n", re_src->r_offset);
>> + continue;
>> + }
>> +
>> /* Get the location from the relocation entry */
>> offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
>>
> Hi Heinrich,
> i just merged recent u-boot master into my devbranch and ran it on my
> board:
>
> --
> U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
>
> CPU: x86, vendor AMD, device 5a2h
> DRAM: 119.6 MiB
> do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0,
> offset = 0x287
> do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8,
> offset = 0x291
> Bus 0: OK
> ---
>
> now i get such relocation warnings, can you help me in this how to deal
> with that?
>
> I'm starting u-boot as a payload from coreboot.
>
> thanks!
>
> cheers,
> Hannes
>
>
Hello Hannes,
thanks for reporting the problem.
There are two possible reasons:
a) The build process introduces relocations of the reported type.
b) The relocation records are overwritten before relocation. This
happens if you update uninitialized globals.
To analyze your problem further, please, provide instructions for
building your version of U-Boot (repository, commit, config). That will
allow to check for a).
Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would
allow to analyze case b). Are you able to reproduce the problem with QEMU?
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt
---
arch/x86/lib/relocate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..01e619d20b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base,
uintptr_t size,
Elf64_Addr *offset_ptr_ram;
do {
+ unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+
+ if (type != R_X86_64_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%llx "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%llx\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size,
Elf32_Addr *offset_ptr_ram;
do {
+ unsigned int type = ELF32_R_TYPE(re_src->r_info);
+
+ if (type != R_386_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%x "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%x\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich,
i just merged recent u-boot master into my devbranch and ran it on my board:
--
U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h
DRAM: 119.6 MiB
do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0,
offset = 0x287
do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8,
offset = 0x291
Bus 0: OK
---
now i get such relocation warnings, can you help me in this how to deal
with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On Sat, Oct 13, 2018 at 9:30 AM Heinrich Schuchardt wrote: > > Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. > We should be warned if other relocation types appear in the relocation > sections. > > This type of message has helped to identify code overwriting a relocation > section before relocation and incorrect parsing of relocation tables. > > Signed-off-by: Heinrich Schuchardt > --- > arch/x86/lib/relocate.c | 18 ++ > 1 file changed, 18 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt
---
arch/x86/lib/relocate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..01e619d20b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base,
uintptr_t size,
Elf64_Addr *offset_ptr_ram;
do {
+ unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+
+ if (type != R_X86_64_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%llx "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%llx\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base,
uintptr_t size,
Elf32_Addr *offset_ptr_ram;
do {
+ unsigned int type = ELF32_R_TYPE(re_src->r_info);
+
+ if (type != R_386_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%x "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%x\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
