On Wed, Jan 18, 2023 at 02:49:31PM -0500, Gregory Price wrote:
On Wed, Jan 18, 2023 at 02:41:00PM -0500, Gregory Price wrote:
---------- Forwarded message --------- From: Peter Zijlstra peterz@infradead.org Date: Wed, Jan 18, 2023 at 12:16 PM Subject: Re: [PATCH 1/3] ptrace,syscall_user_dispatch: Implement Syscall User Dispatch Suspension To: Gregory Price gourry.memverge@gmail.com
On Mon, Jan 09, 2023 at 10:33:46AM -0500, Gregory Price wrote:
@@ -36,6 +37,10 @@ bool syscall_user_dispatch(struct pt_regs *regs) struct syscall_user_dispatch *sd = ¤t->syscall_dispatch; char state;
if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) &&unlikely(current->ptrace &PT_SUSPEND_SYSCALL_USER_DISPATCH))
return false;if (likely(instruction_pointer(regs) - sd->offset < sd->len)) return false;So by making syscall_user_dispatch() return false, we'll make syscall_trace_enter() continue to handle things, and supposedly you want to land in ptrace_report_syscall_entry(), right?
... snip ...
Should setting this then not also depend on having SYSCALL_WORK_SYSCALL_TRACE set? Because without that, you get 'funny' things.
Hm, this is an interesting question. My thoughts are that I want the process to handle the syscall as-if syscall user dispatch was not present at all, regardless of SYSCALL_TRACE.
This is because some software, like CRIU, actually injects syscalls to run in the context of the software in an effort to collect resources.
Oh, right. I used to know that.
So I actually *want* those 'funny' things to occur, because they're most likely intentional. I don't necessarily want to intercept system calls that subsequently occur (although i might).
So if this feature required SYSCALL_TRACE, you would no longer be able to inject system calls ala CRIU.
Yeah, I suppose you're right. It makes it a very sharp instrument, but I suppose you get what you asked for.