linux-kernel - RE: Change signal mask after vfork/clone system call

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:	Wed, 20 Oct 2010 07:56:26 +0000
From:	Gregory Giguashvili <Gregory.Giguashvili@...M.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: Change signal mask after vfork/clone system call

Any comments on this issue? If you think this mailing list is not appropriate for submitting such questions, I would appreciate a pointer to the one that is.
To me, it seems to be related to "clone" system call functionality and flexibility.

Thanks
Giga

-----Original Message-----
From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Gregory Giguashvili
Sent: Tuesday, October 19, 2010 9:54 AM
To: linux-kernel@...r.kernel.org
Subject: Change signal mask after vfork/clone system call

For new processes created by vfork, while signals are blocked using pthread_sigmask: is there a way in a multi-threaded parent to safely unblock signals before the new process is started? Does pthread_atfork like functionality exist for vfork-ed processes maybe?

Ideally, the following code should work, except we're not allowed to call anything in the child process besides exec family of functions.

sigmask_t new;
sigmask_t old;
sigaddset (&new, SIGCHLD);
pthread_sigmask (SIG_BLOCK, &new, &old);

switch (vfork ()) {
case 0: // parent
	break;
case -1: // error
	break;
default: // child
	pthread_sigmask (SIG_SETMASK, &old, NULL);
	execv (...);
	_exit (-1);
}

Finally, if using fork should be efficient for starting processes from applications with heavy VM/RSS memory footprint, this question becomes obsolete.

Thanks
Giga

---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

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