Messages in this thread | | | Date | Tue, 21 Jun 2022 16:05:12 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [PATCH] rseq: x86: Fix rseq_cs get cleared when returning from signal handler |
| |
----- On Jun 21, 2022, at 3:48 PM, Eric W. Biederman ebiederm@xmission.com wrote:
> Derek Bruening <bruening@google.com> writes: > >> From the viewpoint of dynamic binary translation/instrumentation and >> memtrace (go/memtrace), removing those RSEQ_CS_FLAG_NO_RESTART_ON_* flags >> is a good thing as it reduces complexity and makes it easier to handle rseq >> (which is painful enough to handle already). > > It sounds like there is consensus. > > Does someone want to code up a simple patch that detects when > RSEQ_CS_NO_RESTART_ON_SIGNAL and does a WARN_ON_ONCE and fails if > someone uses so it can be set to Linus in the next merge window. > > After no one screams at that patch it should be safe to remove the > functionality, because you have empirical proof that no one uses > that functionality.
Sure, I can whip up something.
I'll send it to Peter Zijlstra shortly.
I plan to, as you suggest, WARN_ON_ONCE() when this happens, and return an error when the rseq flags or rseq_cs flags contain either of the RSEQ_CS_FLAG_NO_RESTART_ON_* flags. This error is handled by forcing a killing the process with sigsegv:
__rseq_handle_notify_resume() [...] error: sig = ksig ? ksig->sig : 0; force_sigsegv(sig);
Does it look acceptable ?
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |