linux-kernel - Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on PREEMPT

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Apr 2022 22:06:30 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-kernel@...r.kernel.org, Ben Segall <bsegall@...gle.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Mel Gorman <mgorman@...e.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on
 PREEMPT_RT.

On Fri, Apr 08, 2022 at 02:40:42PM -0500, Eric W. Biederman wrote:
> Peter Zijlstra <peterz@...radead.org> writes:
> 
> > On Thu, Apr 07, 2022 at 05:50:39PM -0500, Eric W. Biederman wrote:
> 
> >> Given that fundamentally TASK_WAKEKILL must be added in ptrace_stop and
> >> removed in ptrace_attach I don't see your proposed usage of jobctl helps
> >> anything fundamental.
> >> 
> >> I suspect somewhere there is a deep trade-off between complicating
> >> the scheduler to have a very special case for what is now
> >> TASK_RTLOCK_WAIT, and complicating the rest of the code with having
> >> TASK_RTLOCK_WAIT in __state and the values that should be in state
> >> stored somewhere else.
> >
> > The thing is; ptrace is a special case. I feel very strongly we should
> > not complicate the scheduler/wakeup path for something that 'never'
> > happens.
> 
> I was going to comment that I could not understand how the saved_state
> mechanism under PREEMPT_RT works.  Then I realized that wake_up_process
> and wake_up_state call try_to_wake_up which calls ttwu_state_match which
> modifies saved_state.

Correct.

> The options appear to be that either ptrace_freeze_traced modifies
> __state/state to remove TASK_KILLABLE.  Or that something clever happens
> in ptrace_freeze_traced that guarantees the task does not wake
> up.  Something living in kernel/sched/* like wait_task_inactive.

The code I posted in the parent will attempt to strip (and re-instate)
WAKEKILL from __state and then saved_state, all under pi_lock.

I think that preserves the current constraints.

> I can imagine adding add a loop around freezable_schedule in
> ptrace_stop.  That does something like:
> 
> 	do {
>         	freezable_schedule();
>         } while (current->jobctl & JOBCTL_PTRACE_FREEZE);

I'm not entirely sure where you're headin with this; but my goal is to
get rid of freezable_*() everything.

I'll ponder if wait_task_inactive() can simplify things..

> What ptrace_freeze_traced and ptrace_unfreeze_traced fundamentally need
> is that the process to not do anything interesting, so that the tracer
> process can modify the process and it's task_struct.

Agreed, I understand this need. I think I've done this, but I'll
centrainly look hard at it again Monday -- the weekend hopefully
clearing my brain of preconceptions enough so that I can see my own code
a-fresh.

Anyway, my current set lives here:

  https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/wip.freezer

I meant to post earlier today, but stuff got in between and I've not
even done build-tests yet :/