The Linux kernel has introduced a new feature called "Restartable Sequences" or "rseq". This raises multiple problems for dynamic binary instrumentation, including loss of control due to the kernel redirecting the PC and incorrect application behavior due to failing to preserve the semantics of these code sequences. DynamoRIO has looked at and tried to solve these issues for an earlier version of rseq. The new version of rseq, the one that went into the official linux kernel, is more difficult to handle and may require establishing conventions among software developers who use rseq. Given that, it may make sense to collaboratively come up with a solution that works for all dynamic instrumentation frameworks. See Kevin's post to the valgrind-developers list: https://sourceforge.net/p/valgrind/mailman/valgrind-developers/thread/CAB%3DH8NUgjS9Ee7r_VWoBXafAZVYzW1%2BeHPzmA3j-Qeo2n22nmg%40mail.gmail.com/#msg36584233 See a writeup with further details of rseq and ideas for how to handle it here: https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences The kernel commit adding rseq: https://github.com/torvalds/linux/commit/d82991a8688ad128b46db1b42d5d84396487a508
Details on DynamoRIO's "run twice" solution and implementation for the rseq feature which is now generally available in recent kernels are at https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences
glibc will start using rseq: https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html If they get an ENOSYS they will simply not use it. So I propose that for now we "implement" rseq by just returning ENOSYS and not produce an warning for now.
Created attachment 144436 [details] implement rseq as ENOSYS
Updated link for the stale wiki page from the first comment above detailing the run-twice solution DynamoRIO has been using successfully for years now: https://dynamorio.org/page_rseq.html
For now I pushed the ENOSYS patch to make sure things just work with the new glibc. commit 1024237358f01009fe233cb1294f3b8211304eaa Author: Mark Wielaard <mark@klomp.org> Date: Fri Dec 10 17:41:59 2021 +0100 Implement linux rseq syscall as ENOSYS This implements rseq for amd64, arm, arm64, ppc32, ppc64, s390x and x86 linux as ENOSYS (without warning). glibc will start using rseq to accelerate sched_getcpu, if available. This would cause a warning from valgrind every time a new thread is started. Real rseq (restartable sequences) support is pretty hard, so for now just explicitly return ENOSYS (just like we do for clone3). https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html Leaving this bug open for a real implementation.
*** Bug 449199 has been marked as a duplicate of this bug. ***