* Richard W. M. Jones:
That said, ifunc is a very complicated, fragile but powerful mechanism and I'd like to know from the glibc developers what we should look out for. For example:
- Is it ever valid for ifunc to take control of functions in another library? Can this be detected by ld.so?
I'm not sure what you mean by “take control”. The IFUNC resolver returns an address that is used as the symbol value, for the specific symbol the IFUNC resolver was associated with at build time. It's not expected to write to ld.so? data structures directly.
I have patches which make key ld.so? data structures read-only, but they still have to be read-write during relocation processing, when IFUNC resolvers run. Under the defend-against-application-bugs model, that's a reasonable trade-off because IFUNC resolvers are unlikely to have vulnerabilities (currently, they cannot even access environment variables reliably). Of course, it doesn't work for IFUNC resolvers written with malicious intent. I don't think there is a reasonable possibility to defend against that because any ld.so? defense we create is out there for everyone to see, so they can work around that.
- Can some wrappers be developed to make it both easier and safer?
GCC already provides function multi-versioning/target clones as a higher-level interface.
Thanks, Florian