Re: [PATCH v2] ptrace: add PTRACE_GET_RSEQ_CONFIGURATION request

On Thu, Mar 11, 2021 at 09:51:56AM -0500, Mathieu Desnoyers wrote:

----- On Feb 26, 2021, at 8:51 AM, Piotr Figiel figiel@google.com wrote:

quoted

For userspace checkpoint and restore (C/R) a way of getting process state
containing RSEQ configuration is needed.

There are two ways this information is going to be used:
- to re-enable RSEQ for threads which had it enabled before C/R
- to detect if a thread was in a critical section during C/R

Since C/R preserves TLS memory and addresses RSEQ ABI will be restored
using the address registered before C/R.

Detection whether the thread is in a critical section during C/R is needed
to enforce behavior of RSEQ abort during C/R. Attaching with ptrace()
before registers are dumped itself doesn't cause RSEQ abort.
Restoring the instruction pointer within the critical section is
problematic because rseq_cs may get cleared before the control is passed
to the migrated application code leading to RSEQ invariants not being
preserved. C/R code will use RSEQ ABI address to find the abort handler
to which the instruction pointer needs to be set.

To achieve above goals expose the RSEQ ABI address and the signature value
with the new ptrace request PTRACE_GET_RSEQ_CONFIGURATION.

This new ptrace request can also be used by debuggers so they are aware
of stops within restartable sequences in progress.

Signed-off-by: Piotr Figiel <redacted>
Reviewed-by: Michal Miroslaw <redacted>

Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

How do we route this? Do I stick this in tip/sched/core as being an rseq
patch?