"bootelf -p" loads every segement without checking its type

黄 晨曦 chenxi_huang at outlook.com
Tue Mar 14 17:04:27 CET 2023


Hello,

I am making a toy OS kernel on RISC-V platform. The kernel image I built is a ELF file that should be booted using U-Boot's bootelf command. However, I was getting such error when doing bootelf -p <memory address of my ELF file at memory>:

     Unhandled exception: Store/AMO access fault

My kernel file is a 64-bit ELF file with the structure of: (the full readelf report is attached in the email)

```
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  RISCV_ATTRIBUT 0x000000000000c7a0 0x0000000000000000 0x0000000000000000
                 0x0000000000000039 0x0000000000000000  R      0x1
  LOAD           0x0000000000001000 0x0000000080200000 0x0000000080200000
                 0x0000000000001000 0x0000000000001000  R      0x1000
  LOAD           0x0000000000002000 0x0000000080201000 0x0000000080201000
                 0x000000000000a7a0 0x0000000000012890  RWE    0x1000
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10

 Section to Segment mapping:
  Segment Sections...
   00     .riscv.attributes
   01     .entry
   02     .text .rodata .data .bss
   03
​```

The function for loading x64 ELF file to the memory is "unsigned long load_elf64_image_phdr(unsigned long addr)" at lib/elf.c. As I looked into it, the function enumerate every segment and load the segment to the memory. The real problem is that not every segment has to be loaded into the memory. The segment should be loaded if and only if its type is "LOAD". In another words, the function should check "phdr->p_type" first before loading the segment.

I have also looked up codes in QEMU. QEMU has "-kernel" option to load image file directly to the memory, which supports ELF file loading. QEMU checks "phdr->p_type" before loading segments.

Regards,
Chenxi Huang
------------

Background Information:

  *   Linux 5.19.0-35-generic #36~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 17 15:17:25 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

  *   RISC-V GNU Toolchain Version: v2023.01.31 65056bd at riscv-collab/riscv-gnu-toolchain
  *   U-Boot f8f47e6f

-------------- next part --------------
A non-text attachment was scrubbed...
Name: report
Type: application/octet-stream
Size: 30166 bytes
Desc: report
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230314/4e2267ef/attachment.obj>


More information about the U-Boot mailing list