Originally there was a hack in place. Any shared library calls, i.e. 'printf' within a patch, would be resolved by acquiring the symbol data from /lib/shiva itself since it has musl-libc linked statically into it's own binary. This of course worked as a temporary and prototype solution.
We must replace this hack with true and transitive shared object resolution.
Ticket resolved.
Solution:
There is now a Shiva POST linker. shiva_post_linker.c:
When a shared library symbol, such as libc.so:fgets() is being called from a patch object, we can get the symbol.value from the /lib/libc.so library, but we won't know the base address because ld-linux.so hasn't yet been invoked while we're loading and linking our patches into memory. Shiva will have to wait to resolve relinking's and relocation's to of shared library functions untio ld-linux.so has mapped them into memory.
In apply_relocation() when we stumble upon such a symbol we get the symbol value, but don't yet know the base address, so we mark the relocation as DELAYED, thus proposing the concept of "Delayed Relocations". If Shiva finds any Delayed relocations within the patch (That is to say: Any relocations that require shared library resolution) it will enable the "Shiva Post Linker" with shiva_module.c:enable_post_linker() which accesses the auxiliary vector and changes AT_ENTRY value from &_start() (The normal entry point in the target executable) to instead point to &shiva_post_linker() within Shiva.
The post linker is able to apply any delayed relocations, and thus finalize resolution of any shared library symbols.
elfmaster
commented
1 year ago
Originally there was a hack in place. Any shared library calls, i.e. 'printf' within a patch, would be resolved by acquiring the symbol data from /lib/shiva itself since it has musl-libc linked statically into it's own binary. This of course worked as a temporary and prototype solution.
We must replace this hack with true and transitive shared object resolution.
Ticket resolved.
Solution:
There is now a Shiva POST linker. shiva_post_linker.c:
When a shared library symbol, such as libc.so:fgets() is being called from a patch object, we can get the symbol.value from the /lib/libc.so library, but we won't know the base address because ld-linux.so hasn't yet been invoked while we're loading and linking our patches into memory. Shiva will have to wait to resolve relinking's and relocation's to of shared library functions untio ld-linux.so has mapped them into memory.
In apply_relocation() when we stumble upon such a symbol we get the symbol value, but don't yet know the base address, so we mark the relocation as DELAYED, thus proposing the concept of "Delayed Relocations". If Shiva finds any Delayed relocations within the patch (That is to say: Any relocations that require shared library resolution) it will enable the "Shiva Post Linker" with shiva_module.c:enable_post_linker() which accesses the auxiliary vector and changes AT_ENTRY value from &_start() (The normal entry point in the target executable) to instead point to &shiva_post_linker() within Shiva.
The post linker is able to apply any delayed relocations, and thus finalize resolution of any shared library symbols.