Open nwf opened 4 years ago
Rounding down the base shouldn’t be noticeable to RTLD, it just does page-based rounding/truncating here with no notion of representability. What’s obj->vaddrbase
? And what does llvm-readelf -l func-malloc-1
say?
obj->vaddrbase
is 0
and llvm-readelf -l
sayeth
Elf file type is EXEC (Executable file)
Entry point 0x3e3d0
There are 14 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000010040 0x0000000000010040 0x000310 0x000310 R 0x8
INTERP 0x000350 0x0000000000010350 0x0000000000010350 0x000015 0x000015 R 0x1
[Requesting program interpreter: /libexec/ld-elf.so.1]
LOAD 0x000000 0x0000000000010000 0x0000000000010000 0x01e3c4 0x01e3c4 R 0x10000
LOAD 0x01e3d0 0x000000000003e3d0 0x000000000003e3d0 0x01e47c 0x01e47c R E 0x10000
LOAD 0x03c850 0x000000000006c850 0x000000000006c850 0x000030 0x000030 RW 0x10000
LOAD 0x03c880 0x000000000007c880 0x000000000007c880 0x001060 0x082780 RW 0x10000
TLS 0x03c850 0x000000000006c850 0x000000000006c850 0x000008 0x000019 R 0x8
DYNAMIC 0x003980 0x0000000000013980 0x0000000000013980 0x0001b0 0x0001b0 R 0x8
GNU_RELRO 0x03c850 0x000000000006c850 0x000000000006c850 0x000030 0x0007b0 R 0x1
GNU_EH_FRAME 0x019fa0 0x0000000000029fa0 0x0000000000029fa0 0x000e8c 0x000e8c R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x0
NOTE 0x000368 0x0000000000010368 0x0000000000010368 0x000048 0x000048 R 0x4
OPTIONS 0x0003c8 0x00000000000103c8 0x00000000000103c8 0x000028 0x000028 R 0x8
ABIFLAGS 0x0003b0 0x00000000000103b0 0x00000000000103b0 0x000018 0x000018 R 0x8
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.tag .MIPS.abiflags .MIPS.options .dynsym .gnu.version .gnu.version_r .hash .dynamic .dynstr .rodata .eh_frame_hdr .eh_frame
03 .text .init .fini
04 .tdata .ctors .dtors .jcr
05 .data .rld_map .got .bss
06 .tdata .tbss
07 .dynamic
08 .tdata .ctors .dtors .jcr
09 .eh_frame_hdr
10
11 .note.tag
12 .MIPS.options
13 .MIPS.abiflags
None .comment .pdr .debug_loc .debug_abbrev .debug_info .debug_str .debug_line .debug_frame .debug_aranges .debug_ranges .gdb_index .symtab .shstrtab .strtab
```</s>
That doesn’t seem consistent with your original output.
(Though I have noticed that we don’t do the right thing when there’s only one PT_LOAD, as it’s both the first and last segment...)
D'oh. Too many build directories. Sorry, try this llvm-readelf -l
intead:
Elf file type is DYN (Shared object file)
Entry point 0x2e760
There are 14 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000310 0x000310 R 0x8
INTERP 0x000350 0x0000000000000350 0x0000000000000350 0x000015 0x000015 R 0x1
[Requesting program interpreter: /libexec/ld-elf.so.1]
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x01e758 0x01e758 R 0x10000
LOAD 0x01e760 0x000000000002e760 0x000000000002e760 0x0205a0 0x0205a0 R E 0x10000
LOAD 0x03ed00 0x000000000005ed00 0x000000000005ed00 0x000020 0x000020 RW 0x10000
LOAD 0x06ed20 0x000000000006ed20 0x000000000006ed20 0x0022c0 0x80512e0 RW 0x40000
TLS 0x03ed00 0x000000000005ed00 0x000000000005ed00 0x000010 0x000021 R 0x10
DYNAMIC 0x003738 0x0000000000003738 0x0000000000003738 0x000250 0x000250 R 0x8
GNU_RELRO 0x03ed00 0x000000000005ed00 0x000000000005ed00 0x000020 0x000300 R 0x1
GNU_EH_FRAME 0x015940 0x0000000000015940 0x0000000000015940 0x000df4 0x000df4 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x0
NOTE 0x000368 0x0000000000000368 0x0000000000000368 0x000048 0x000048 R 0x4
OPTIONS 0x0003c8 0x00000000000003c8 0x00000000000003c8 0x000028 0x000028 R 0x8
ABIFLAGS 0x0003b0 0x00000000000003b0 0x00000000000003b0 0x000018 0x000018 R 0x8
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.tag .MIPS.abiflags .MIPS.options .dynsym .gnu.version .gnu.version_r .hash .dynamic .dynstr .rel.dyn .rel.plt .rodata .eh_frame_hdr .eh_frame __cap_relocs
03 .text
04 .tdata .ctors .dtors
05 .data .captable .rld_map .got .bss
06 .tdata .tbss
07 .dynamic
08 .tdata .ctors .dtors
09 .eh_frame_hdr
10
11 .note.tag
12 .MIPS.options
13 .MIPS.abiflags
None .comment .pdr .debug_loc .debug_abbrev .debug_info .debug_str .debug_line .debug_ranges .gdb_index .symtab .shstrtab .strtab
Working on
snmalloc
CHERIfication, I was rewarded with (well, after I also turned on rtld debugging)That exception comes from https://github.com/CTSRD-CHERI/cheribsd/blob/1507c329a5e8111cea1facedcbfd82283ddc25f2/libexec/rtld-elf/rtld.c#L1875
obj->relocbase
is derived from theAT_PHDR
aux vector entry at https://github.com/CTSRD-CHERI/cheribsd/blob/1507c329a5e8111cea1facedcbfd82283ddc25f2/libexec/rtld-elf/rtld.c#L1782 andobj->mapsize
is computed at https://github.com/CTSRD-CHERI/cheribsd/blob/1507c329a5e8111cea1facedcbfd82283ddc25f2/libexec/rtld-elf/rtld.c#L1817gdb
thinks that, at the time of the fault,obj->mapsize
worked out to being0x80c0000
(i.e., the length of theAT_PHDR
cap and also the value in$at
) andobj->relocbase
was(caddr_t) 0x120000 [rwRW,0x100000-0x81c0000] "\177ELF\002\002\001\t\003"
(which matches what's in$c01
).Is this program being mis-loaded by the kernel? Is this a case where we've had to round the base down to achieve alignment and that's throwing off the delicate dance?