On Thu, Jul 30, 2020 at 9:54 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Jann Horn: > > > On Thu, Jul 30, 2020 at 6:02 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >> Functions no longer start with the ENDBR64 prefix. Instead, the link > >> editor produces a PLT entry with an ENDBR64 prefix if it detects any > >> address-significant relocation for it. The PLT entry performs a NOTRACK > >> jump to the target address. This assumes that the target address is > >> subject to RELRO, of course, so that redirection is not possible. > >> Without address-significant relocations, the link editor produces a PLT > >> entry without the ENDBR64 prefix (but still with the NOTRACK jump), or > >> perhaps no PLT entry at all. > > > > How would this interact with function pointer comparisons? As in, if > > library A exports a function func1 without referencing it, and > > libraries B and C both take references to func1, would they end up > > with different function pointers (pointing to their respective PLT > > entries)? > > Same as today. ELF already deals with this by picking one canonical > function address per process. > > Some targets already need PLTs for inter-DSO calls, so the problem is > not new. It happens even on x86 because the main program can refer to > its PLT stubs without run-time relocations, so those determine the > canonical address of those functions, and not the actual implementation > in a shared object. > > > Would this mean that the behavior of a program that compares > > function pointers obtained through different shared libraries might > > change? > > Hopefully not, because that would break things quite horribly (as it's > sometimes possible to observe if the RTLD_DEEPBIND flag is used). > > Both the canonicalization and the fact in order to observe the function > pointer, you need to take its address should take care of this. > > > I guess you could maybe canonicalize function pointers somehow, but > > that'd probably at least break dlclose(), right? > > Ahh, dlclose. I think in this case, my idea to generate a PLT stub > locally in the address-generating DSO will not work because the > canonical address must survive dlclose if it refers to another DSO. > There are two ways to deal with this: do not unload the PLT stub until > the target DSO is also unloaded (but make sure that the DSO can be > reloaded at a different address; probably not worth the complexity), > or use the dlsym hack I sketched for regular symbol binding as well. > Even more room for experiments, I guess. > > Thanks, > Florian FWIW, we can introduce a different CET PLT as long as it is compatible with the past, current and future binaries. -- H.J.
