On Thu, Feb 10, 2022 at 11:41:16PM -0800, avagin@gmail.com wrote:

On Wed, Feb 09, 2022 at 06:37:53PM -0800, Andy Lutomirski wrote:

quoted

An alternative would be to add a bona fide ptrace call-a-function mechanism.
I can think of two potentially usable variants:

1. Straight call.  PTRACE_CALL_FUNCTION(addr) just emulates CALL addr,
shadow stack push and all.

2. Signal-style.  PTRACE_CALL_FUNCTION_SIGFRAME injects an actual signal
frame just like a real signal is being delivered with the specified handler.
There could be a variant to opt-in to also using a specified altstack and
altshadowstack.

I think this would be ideal. In CRIU, the parasite code is executed in
the "daemon" mode and returns back via sigreturn.  Right now, CRIU needs
to generate a signal frame. If I understand your idea right, the signal
frame will be generated by the kernel.

quoted

2 would be more expensive but would avoid the need for much in the way of
asm magic.  The injected code could be plain C (or Rust or Zig or whatever).

All of this only really handles save, not restore.  I don't understand
restore enough to fully understand the issue.

In a few words, it works like this: CRIU restores all required resources
and prepares a signal frame with a target process state, then it
switches to a small PIE blob, where it restores vma-s and calls
rt_sigreturn.

I think it's also important to note that the stack is restored as a part of
the process memory, i.e. its contents is read from the images.
 

quoted

--Andy

-- 
Sincerely yours,
Mike.