linux-kernel - Re: [patch 3/14] x86, ptrace, bts: stop bts tracing early in do

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]

Message-ID: <20090330012204.GA2058@redhat.com>
Date:	Mon, 30 Mar 2009 03:22:04 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Markus Metzger <markus.t.metzger@...glemail.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	"Metzger, Markus T" <markus.t.metzger@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>,
	"roland@...hat.com" <roland@...hat.com>,
	"eranian@...glemail.com" <eranian@...glemail.com>,
	"Villacis, Juan" <juan.villacis@...el.com>,
	"ak@...ux.jf.intel.com" <ak@...ux.jf.intel.com>
Subject: Re: [patch 3/14] x86, ptrace, bts: stop bts tracing early in
	do_exit

On 03/28, Markus Metzger wrote:
>
> ds_release_bts(struct bts_tracer *tracer)
> {
> 	struct task_struct *task =
> 		tracer->ds.context->task;
>
> 	do {
> 		set_task_state(task, TASK_UNINTERRUPTIBLE);

Oh, this is not right,

> 	while (!wait_task_inactive(task, TASK_UNINTERRUPTIBLE));

and can't help to wait_task_inactive(). Again, unless this task
does a blocking call wait_task_inactive() can't force this task
to be deactivated. Even we set TASK_UNINTERRUPTIBLE.

> 	ds_suspend_bts(tracer);
> 	ds_free_bts(tracer);
>
> 	wake_up_process(task);

makes it TASK_RUNNING. This can't restores the proper ->state
if it was not running (say, TASK_STOPPED).

> }
>
> I guess it would not work in general, since task could already sleep
> on some event and be woken up after the do loop.

This too,

> I was thinking it might work for the exit race, since we don't sleep
> during exit,

We do. In the context of bts problems, we don't care if the task sleeps
after _free_tracee(). But this task can have tracees too, it can in turn
sleep in wait_task_inactive().

> Isn't this a general problem for ptrace?
>
> Ptrace uses a similar pattern in ptrace_check_attach().
> It stops the traced task, but that task might wake up immediately after
> that check. It might be scheduled in any time during a ptrace operation.

Yes. ptrace() can assume the tracee is TASK_TRACED, or it is dying/dead.

If you need to make sure it is still traced, you can re-check ->state
under ->siglock. Until you drop this lock, the tracee (if still traced)
can't escape from ptrace_stop/do_signal_stop, even if scheduled.

Oleg.

--
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/