On Thu, Mar 3, 2022 at 11:43 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > On Mon, Feb 28, 2022 at 02:55:30PM -0800, Andy Lutomirski wrote: > > > > > > On Mon, Feb 28, 2022, at 1:30 PM, Mike Rapoport wrote: > > > On Mon, Feb 28, 2022 at 12:30:41PM -0800, Andy Lutomirski wrote: > > >> > > >> > > >> On Mon, Feb 28, 2022, at 12:27 PM, Mike Rapoport wrote: > > >> > On Wed, Feb 09, 2022 at 06:37:53PM -0800, Andy Lutomirski wrote: > > >> >> On 2/8/22 18:18, Edgecombe, Rick P wrote: > > >> >> > On Tue, 2022-02-08 at 20:02 +0300, Cyrill Gorcunov wrote: > > >> >> > > > >> > > > >> > Even with the current shadow stack interface Rick proposed, CRIU can restore > > >> > the victim using ptrace without any additional knobs, but we loose an > > >> > important ability to "self-cure" the victim from the parasite in case > > >> > anything goes wrong with criu control process. > > >> > > > >> > Moreover, the issue with backward compatibility is not with ptrace but with > > >> > sigreturn and it seems that criu is not its only user. > > >> > > >> So we need an ability for a tracer to cause the tracee to call a function > > >> and to return successfully. Apparently a gdb branch can already do this > > >> with shstk, and my PTRACE_CALL_FUNCTION_SIGFRAME should also do the > > >> trick. I don't see why we need a sigretur-but-dont-verify -- we just > > >> need this mechanism to create a frame such that sigreturn actually works. > > > > > > If I understand correctly, PTRACE_CALL_FUNCTION_SIGFRAME() injects a frame > > > into the tracee and makes the tracee call sigreturn. > > > I.e. the tracee is stopped and this is used pretty much as PTRACE_CONT or > > > PTRACE_SYSCALL. > > > > > > In such case this defeats the purpose of sigreturn in CRIU because it is > > > called asynchronously by the tracee when the tracer is about to detach or > > > even already detached. > > > > The intent of PTRACE_CALL_FUNCTION_SIGFRAME is push a signal frame onto > > the stack and call a function. That function should then be able to call > > sigreturn just like any normal signal handler. > > Ok, let me reiterate. > > We have a seized and stopped tracee, use PTRACE_CALL_FUNCTION_SIGFRAME > to push a signal frame onto the tracee's stack so that sigreturn could use > that frame, then set the tracee %rip to the function we'd like to call and > then we PTRACE_CONT the tracee. Tracee continues to execute the parasite > code that calls sigreturn to clean up and restore the tracee process. > > PTRACE_CALL_FUNCTION_SIGFRAME also pushes a restore token to the shadow > stack, just like setup_rt_frame() does, so that sys_rt_sigreturn() won't > bail out at restore_signal_shadow_stack(). That is the intent. > > The only thing that CRIU actually needs is to push a restore token to the > shadow stack, so for us a ptrace call that does that would be ideal. > That seems fine too. The main benefit of the SIGFRAME approach is that, AIUI, CRIU eventually constructs a signal frame anyway, and getting one ready-made seems plausibly helpful. But if it's not actually that useful, then there's no need to do it.
