linux-kernel - Re: [PATCH 6/9] job control: make task_clear_jobctl

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:	Mon, 16 May 2011 15:24:00 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	jan.kratochvil@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 6/9] job control: make task_clear_jobctl_pending()
 clear TRAPPING automatically

Hello,

On Mon, May 16, 2011 at 02:25:35PM +0200, Oleg Nesterov wrote:
> On 05/13, Tejun Heo wrote:
> >
> > @@ -264,6 +267,9 @@ void task_clear_jobctl_pending(struct task_struct *task, unsigned int mask)
> >  		mask |= JOBCTL_STOP_CONSUME | JOBCTL_STOP_DEQUEUED;
> >
> >  	task->jobctl &= ~mask;
> > +
> > +	if (!(task->jobctl & JOBCTL_PENDING_MASK))
> > +		task_clear_jobctl_trapping(task);
> >  }
> 
> So, SIGCONT clears JOBCTL_TRAPPING and wakes up the tracer.

If JOBCTL_TRAPPING is set && JOBCTL_STOP_PENDING was the only pending
condition.

> I can't really understand this without seeing the next changes, but
> it seems this makes some things worse, although I am not sure.

It's a safety mechanism.  We shouldn't have TRAPPING set when no
stop/trap is pending and the above establishes that invariant and will
also be used to simplify exception cases where all pending conditions
are cleared (tracee being killed).  It's conceptually much easier to
grasp that way - you clear all pending conditions when the task dies
and the mechanism to wait for trap transition is cleared together.

> For example. PTRACE_SEIZE should guarantee the tracee will trap and
> report. However, if the tracee is stopped during attach, we can race
> with SIGCONT. The previous version had the similar problem afaics, but
> it was easy (I think) to fix. Now that SIGCONT clears JOBCTL_TRAPPING
> we need more complications.

This problem doesn't exist anymore.  SEIZE directly schedules
JOBCTL_TRAP_STOP instead of using JOBCTL_STOP_PENDING, so it actually
works exactly as it should.

1. If tracee was stopped and tracer attaches, tracee should re-trap
   and tracer should wait for TRAPPING.

2. If tracee was not stopped and tracer attaches, tracee traps to
   STOP.

3. If tracee was stopped and tracer attaches but SIGCONT is received
   before TRAPPING is done, TRAPPING is cleared and tracer and tracee
   are in the same conditions as #2, which is exactly how they should
   be.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/