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-next>] [day] [month] [year] [list]
Message-ID: <20080319003112.GA183@tv-sign.ru>
Date:	Wed, 19 Mar 2008 03:31:12 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Pavel Emelyanov <xemul@...nvz.org>, linux-kernel@...r.kernel.org
Subject: Re: rfc, leader_pid_type()

On 03/18, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@...sign.ru> writes:
> 
> > On 03/18, Eric W. Biederman wrote:
> >>
> >> Oleg Nesterov <oleg@...sign.ru> writes:
> >> 
> >> > Eric, Pavel.
> >> >
> >> > Without tasklist lock held, task_tgid/task_pgrp/task_session can return the
> >> > bogus NULL. Note that the last 2 can return NULL even if task == current.
> >> >
> >> > What do you think if we add yet another helper?
> >> 
> >> My current inclination is this places the cost for de_thread in the
> >> wrong place.  exec on a threaded binary should be rare.
> >> Any chance we can make de_thread rcu safe?
> >> 
> >> We are very close.
> >> 
> >> It would take a double check but I believe all we need to do is to
> >> modify detach_pid to remove link->pid.  This of course messes up
> >> pid_alive but otherwise we should be ok if we have a big fat comment.
> >
> > Not sure I understand... detach_pid(type) already sets
> >
> > 	task->pids[type].pid = NULL;
> 
> Sorry.  I meant to remove that line that clears task->pids[type].pid 
> If we don't set .pid to NULL we can still dereference while the task_struct
> is rcu reachable.

!!!!! Yes you are right.

No, we don't need to change detach_pid(), but we can change transfer_pid()
and kill this line:

	old->pids[type].pid = NULL;

this can't break de_thread()->release_task(leader)->__unhash_process()
because leader is not group_leader() any longer.

And with this change we can't see task_session() == NULL under rcu_read_lock()
during exec, great!

And. this doesn't break do_each_pid_task(PIDTYPE_SID), we can't see both
old and new leaders.

> >> We might need to replace the detach_pid, attach_pid sequence in
> >> __set_special_pids with an optimized sequence like transfer_pid
> >> call it replace_pid where we guarantee there is always a valid pid
> >> pointer in the group_leader.
> >
> > OK... I think you are right... good point.

Yes, good point. Except we need a couple of subtle but straightforward
changes, but I think this change worth it.

Perhaps I (or you ;) missed something, I'll re-check... but this all
looks like a good plan, thanks!

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ