On Fri, Nov 5, 2021 at 10:54 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches > wrote: > > I had the impression we have support for PCH file relocation to deal with > > ASLR > > at least on some platforms. > > Unfortunately we do not, e.g. if you build cc1/cc1plus as PIE on > x86_64-linux, PCH will stop working unless one always invokes it with > disabled ASLR through personality. > > I think this is related to function pointers and pointers to .rodata/.data > etc. variables in GC memory, we currently do not relocate that. > > What we perhaps could do is (at least assuming all the ELF PT_LOAD segments > are adjacent with a single load base for them - I think at least ia64 > non-PIE binaries were violating this by having .text and .data PT_LOAD > segments many terrabytes appart with a whole in between not protected in any > way, but dunno if that is for PIEs too), perhaps try in a host > specific way remember the address range in which the function pointers and > .rodata/.data can exist, remember the extent start and end from PCH generation > and on PCH load query those addresses for the current compiler and relocate > everything in that extent by the load bias from the last run. > But, the assumption for this is that those function and data/rodata pointers > in GC memory are actually marked at least as pointers...
If any such pointers exist they must be marked GTY((skip)) since they do not point to GC memory... So we'd need to invent special-handling for those. > Do we e.g. have objects with virtual classes in GC memory and if so, do we > catch their virtual table pointers? Who knows, but then I don't remember adding stuff that should end in a PCH. Honestly I don't think it's worth spending too much time in making this work. Iff then disallow pointers to outside GC in PCH (maybe code abort() or mark_invalid_pch calls into the pch walkers when they reach a GTY((skip))) Richard. > Jakub >
