If we are simply restarting a syscall, there's no need to do anything afterwards
to restore any register values so we don't really need to keep a record of it ourselves
in the chain syscall list.
By simply resetting the PC and the arguments, we avoid issue #292 for this function
when we get a signal before we run the restarted syscall and confused syscall
from the signal handler as the one we restarted (chained).
When the ptracer waits on a non-immediate child,
the information is only available in the zombies list and we need to handle those ourselves.
Expands the tracee lookup of the wait enter to include zombies of the tracee to handle this.
The new test mimicing the testing operation from gdb's `linux_check_ptrace_features`.
* Enable github action for testing
Add a `QUIET_LOG` option for the test makefile to allow printing the full log
while still having a nice summary of the test results.
Co-authored-by: Lucas Ramage <lucas.ramage@infinite-omicron.com>
The event handler for the old kernel may still be called on new kernels.
This causes issues since the two event handlers maintains their own global states
unaware of each other.
In particular, execve+ptrace handling from the loader of the tracee
will issue an `execve(0x1, ...)` to signal proot of the start addresses.
This triggers a `SIGTRAP` to the tracee for the tracer to handle.
However, the event handler expect one initial `SIGTRAP` to have special meaning
and if the wrong event handler is called, it will incorrectly assume this `SIGTRAP`
is the special one and acts incorrectly. (In this case, causing the signaling `execve`
to run again and set the addresses incorrectly.)
When running under seccomp, sometimes sysexit handlers fail to execute.
This is possible when the first syscall a process makes,
before seccomp is enabled, gets handled in the SIGTRAP path.
However the conditions for this to occur seem fairly random,
so we fork out many processes to make it likely that at least
some hit this problem.
This problem may be related to issue #106.
Yichao Yu