[PATCH] D64906: [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges

Fri Jul 19 06:17:35 PDT 2019

MaskRay added a comment.

> I would like to do a bit more research about RELRO, as I can't see from this patch alone. I think it is fine if RELRO is double mapped into an RO page.

Yes, the RELRO region may be double mapped.

> As in theory (I'm not sure about how this works in the OS/loader so I could have this wrong) if the physical contents of .data was mapped RW from 0x10000 -> 0x20000 we'd have an ability to write to the .data.rel.ro via .data.

This should not be a concern. PT_LOAD segments are mapped with the MAP_PRIVATE flag. The contents are copy-on-write and not shared between two maps:

  MAP_PRIVATE
     Create  a  private copy-on-write mapping.  Updates to the mapping are not visible to other pro‐
     cesses mapping the same file, and are not carried  through  to  the  underlying  file.   It  is
     unspecified  whether  changes  made to the file after the mmap() call are visible in the mapped
     region.

> To answer my own question https://sourceware.org/binutils/docs-2.32/ld/Builtin-Functions.html has DATA_SEGMENT_RELRO_END which mentions:
> 
> There is also the comment in DATA_SEGMENT_ALIGN

Thanks for the reference! I see that document partly answered my point 5 above (https://reviews.llvm.org/D64906#1592854). Their choice is to avoid maxpagesize alignment at the end of PT_GNU_RELRO, but there can still be a commonpagesize alignment at DATA_SEGMENT_ALIGN. The downside is that the last page may not be protected (common case on PPC: commonpagesize=4k, pagesz=maxpagesize=64k).

Since D58892 <https://reviews.llvm.org/D58892>, we have two RW segments: RW(relro) + RW(non-relro). By allowing double mapped RELRO contents, we don't have an alignment. (Our .got and .got.plt are separate - which has been the case for a long time. There seems no issue with it.)

Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64906/new/

https://reviews.llvm.org/D64906