From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7048 invoked by alias); 19 Dec 2014 21:01:28 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 6420 invoked by uid 48); 19 Dec 2014 21:01:21 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17214] Expose a clone variant that shares stacks instead of jumping to a new one Date: Fri, 19 Dec 2014 21:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg00169.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17214 --- Comment #14 from Rich Felker --- Your claim that "vfork sets all memory except the current stack as read only in the process" is false and generally impossible to implement for various reasons. At the kernel level vfork is identical to clone with flags=CLONE_VM|CLONE_VFORK|SIGCHLD, and all CLONE_VFORK does is block scheduling of the parent until the child successfully execs or terminates. By "eliminated", I meant dropped from the standards and deprecated. Of course it still exists in implementations that provide it, but the formalism for what you can do after vfork is wrong with respect to compiler semantics and thus it's unusable. For instance in the code: if (!(pid = vfork())) { execve(...); _exit(1); } the traditional rules have been followed, but since _exit is a _Noreturn function, the compiler is free to write the arguments for execve over top of storage that was being used for local variables or spilled/saved registers in the caller (assuming their addresses are not visible to execve). This is valid because they can never be accessed again in the child. But since the child and parent share memory, the parent's stack will be trashed when it resumes execution. There are hacks that could be done at the compiler level to recognize vfork as special and avoid this, but it's a game of whack-a-mole. Sharing a stack between processes is just a broken design. -- You are receiving this mail because: You are on the CC list for the bug.