Followups from #19525 #19623

There's the possibility to follow up with another test and to investigate some behaviour noticed by @laanwj, that resulted in this comment:

edit: the load offset for the writable data is curious: 0x00000000008f7920 is not page aligned, and right after the read-only data, does this mean read-only and read-write data are stilll allowed to share a page?

I'm still spooked by this, by the way. Not sure if it is an (upstream) bug or expected behavior. I thought about adding a check that LOAD ranges with different permissions don't overlap on the same memory pages, but this is a clear violation of this, making the separation less effective.

(in any case, not a reason to not move forward with this as it is, better is better)

Edit: it does seem to work out locally, maybe I just miscounted? I've added a per-page permission check in this commit: https://github.com/laanwj/bitcoin/commit/9d9fcefcaec3d638f472ea77c146eaec8f9079c1

It may also be the case that this is expected, and we just need to confirm that.

I think I found the spot in the ELF spec that describes what @laanwj observed, in Book III, Section 2, Base Address (page 73), emphasis mine:

An executable or shared object file's base address is calculated during execution from three values: the virtual memory load address, the maximum page size, and the lowest virtual address of a program's loadable segment. To compute the base address, one determines the memory address associated with the lowest p_vaddr value for a PT_LOAD segment. This address is truncated to the nearest multiple of the maximum page size. The corresponding p_vaddr value itself is also truncated to the nearest multiple of the maximum page size. The base address is the difference between the truncated memory address and the truncated p_vaddr value.

The segment needs to eventually be mmap-ed and mmap needs a page-aligned offset, so the loader will round these values down to the nearest page offset and mmap will add some extra space to the beginning of the map to compensate.

My interpretation therefore is that this means the rw and r LOAD segments will not overlap on a page, but I am unsure how to test this in practice. Output from my default linker script (ld --verbose) appears to show this alignment taking place:

<snip>
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

<snip>

  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);
  . = ALIGN(CONSTANT (MAXPAGESIZE));
  /* Adjust the address for the rodata segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  . = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)));
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
  .rodata1        : { *(.rodata1) }
  .eh_frame_hdr   : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) }
  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) }
  .gcc_except_table   : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
  .gnu_extab   : ONLY_IF_RO { *(.gnu_extab*) }
  /* These sections are generated by the Sun/Oracle C++ compiler.  */
  .exception_ranges   : ONLY_IF_RO { *(.exception_ranges*) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
<snip>

Going to close this for now.