* 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