linux-kernel - Re: [PATCH 1/3] ptrace,syscall_user_dispatch: Implement Syscall User Dispatch Suspension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y8hZQI6UfDHhH3tj@hirez.programming.kicks-ass.net>
Date:   Wed, 18 Jan 2023 21:40:32 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Gregory Price <gregory.price@...verge.com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
        krisman@...labora.com, tglx@...utronix.de, luto@...nel.org,
        oleg@...hat.com, ebiederm@...ssion.com, akpm@...ux-foundation.org,
        adobriyan@...il.com, corbet@....net, shuah@...nel.org
Subject: Re: [PATCH 1/3] ptrace,syscall_user_dispatch: Implement Syscall User
 Dispatch Suspension

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@...radead.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@...il.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 = &current->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.