linux-kernel - Re: [PATCH 0/8] make vfork killable/restartable/traceable

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: <20110729192358.GB31717@mtj.dyndns.org>
Date:	Fri, 29 Jul 2011 21:23:58 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roland McGrath <roland@...k.frob.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Matt Fleming <matt.fleming@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] make vfork killable/restartable/traceable

Hello, Oleg.

On Wed, Jul 27, 2011 at 06:31:59PM +0200, Oleg Nesterov wrote:
> 	- is it safe to exit/stop on !x86 machine???
> 
> 	  I do not know. May be this needs some #ifdef's around
> 	  wait_for_completion_interruptible(). I am not sure that,
> 	  say, arch_ptrace_stop() can't abuse the ->mm shared with
> 	  the child.
>
> 	  OTOH. This can happen anyway, do_fork() does ptrace_event()
> 	  before wait_for_completion().

The only affected architecture would be ia64 thanks to the rolling
register stack.  I suspected it would unroll on fork but couldn't
determine whether it actually does that.  At any rate, it should be
safe as the child isn't allowed to return from the forking function
and arch_ptrace_stop() unrolling the register stack shouldn't affect
the child.  Eh... too much speculation, probably best to ask ia64 ppl.

A wild, possibly bat-shit crazy idea about the whole series:

If the current implementation is too nasty, an alternative approach
could be handling vfork waiting as a type of job control stop.
ie. while a task has vforked children, it's considered to have sticky
STOP state and can't leave get_signal_to_deliver() unless killed.  I
think this could be a bit more natural than trying to allow restart of
vfork().

So, very roughly, something like the following for the parent.

* On vfork(), mark vfork child exists and set TIF_SIGPENDING.

* When entering get_signal_to_deliver(), if vfork child exists, save
  sigmask and block all blockable signals.

* If dequeue_signal() returns 0 && vfork child exists, enter STOP.

* When leaving get_signal_to_deliver(), restore sigmask if saved on
  entry.

Haven't really thought a lot about the details so this might end up
uglier than the current attempt.  :)

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/