[PATCH] RFC: Provide a function to reset IFUNC PLTs

[Adhemerval Zanella Netto]

On 08/03/23 07:21, Jan Kratochvil wrote:
> On Tue, 07 Mar 2023 21:07:58 +0800, Adhemerval Zanella Netto wrote:
>> I am not sure if the ifunc reset will be really safe without adding CRIU
>> migrate sync points, to avoid suspend execution in a context that the
>> ifunc variants are already being executed or its address is being in a
>> function point (for instance in PLT code).
> 
> You are right but I left the thread safety up to the caller ("Freezer"):
> 	https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6029
> 
> It could be moved to the glibc part.
> 
> 
>> Besides, I also not sure if adding way to remove RELRO protection won't
>> add more security issues (we can disable for sesuid binaries, but even
>> though it is not a good security practice).
> 
> RELRO is removed only temporarily, it gets re-engaged. And that time other
> threads should be even stopped (see above). Is it still a security issues?

Yes, without a stop-the-world scheme where a helper thread sets PR_GET_DUMPABLE 
and PTRACE_ATTACH the process can not really be sure that any new thread will not 
be created between the time you enumerate the process threads and call the 'freeze'
function.

I really don't think glibc should provide an interface to temporary disable any
security hardening, it should always opt-in at either program startup or by
building time.  The ifunc mechanism is already full or corner cases and I think
adding a runtime mechanism to reset them is *not* a way forward.  

As I said, I think CRIU heterogeneity should be handled by masking off the higher 
cpu features.  I am not if ARCH_SET_CPUID would a solution here, it means that
we will need to handle SIGSEGV in the loader and come up with a sane subset
in case of failure (we now have x86_64-vx, so we can use it as default). 

But as Florian has said, fixing on glibc won't work consistently on other
libraries that uses cpuid instruction.  And yes, I am aware we are discussing
glibc, but I prefer a composable solution (like adding proper cpuid maskoff in 
the kernel) to add an ah-hoc one.