Re: [Qemu-devel] How to make ELF headers/symbol sections available for multiboot?

[Richard Henderson]

On 07/31/2017 10:21 AM, Anatol Pomozov wrote:
> ELF sections info is needed for an OS to map address space properly.

No, ELF *program header* info is needed for an OS to map the address space
properly.  For example:

$ readelf -hl vmlinux-4.9.0-3-5kc-malta

Using a mips kernel binary I happend to have handy; it would be the same for
x86_64, prior to being bundled in the (imo superfluous bzImage) format.

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0xffffffff806ed590
  Start of program headers:          64 (bytes into file)
  Start of section headers:          13351328 (bytes into file)
  Flags:                             0x80000001, noreorder, mips64r2
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 27

The ELF file header, always at file offset 0.  The relevant info is the
encoding (64-bit little-endian), cpu (mips), and start of program headers.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0xffffffff80100000 0xffffffff80100000
                 0x00000000009fefb4 0x0000000000a5a150  RWE    1000
  NOTE           0x00000000005fecb0 0xffffffff806fdcb0 0xffffffff806fdcb0
                 0x0000000000000024 0x0000000000000024  R      4

The ELF program header.  There is one segment to be loaded, at a given physical
address (which happens to match the virtual address, but that need not have
been so).

The segment consists of 0x9fefb4 bytes of data to be loaded from the file, and
occupies 0xa5a150 in memory.  The difference between the two sizes is "bss",
and should be zeroed.

A proper ELF loader will process *all* LOAD segments, however many are required
by the binary.  Though in practice there will probably only be 1 or 2.

Section to Segment mapping:
  Segment Sections...
  00     .text __ex_table __dbe_table .notes .rodata .pci_fixup __ksymtab
__ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver .data
.data..page_aligned .init.text .init.data .exit.text .data.reloc .sbss .bss
  01     __dbe_table .notes

This mapping is provided by readelf for convenience, not actually present in
the ELF file.  But it is handy when debugging a linker script.

> Quoting Multiboot specification
> https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

I'm not sure why someone felt the need to re-invent the wheel, especially
considering its introduction section talks about trying to stop reinventing the
wheel...

But... whatever.  I'm not sure why this is relevant to $SUBJECT, since it does
not appear to have anything to do with ELF at all.


r~