On Thu, Feb 10, 2022 at 11:41:16PM -0800, avagin@xxxxxxxxx wrote: > On Wed, Feb 09, 2022 at 06:37:53PM -0800, Andy Lutomirski wrote: > > > > 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. > > > > > 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. > > > > --Andy -- Sincerely yours, Mike.
