From owner-freebsd-arch Mon Oct 29 13:31:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 1F9B437B405; Mon, 29 Oct 2001 13:31:54 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15yK0e-000DpQ-0U; Mon, 29 Oct 2001 21:31:52 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9TLUb765618; Mon, 29 Oct 2001 21:30:37 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 29 Oct 2001 21:30:37 +0000 (GMT) From: Doug Rabson To: Julian Elischer Cc: Jake Burkholder , John Baldwin , Subject: Re: syscall() ABI questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 29 Oct 2001, Julian Elischer wrote: > But the API for vfork forbids the child from doing a 'ret' after the vfork > returns.. if it does that, all bets are off.... you can do: > vfork(); > exec(); > > and that 's about all that's ok... > I'm not even sure about > vfork(); > exit(); I think the point is that the vfork stub has to return back to the function which is intending to call exec() and therefore exposes the memory location which held the return address to possible corruption (certain corruption considering that the call to exec will push stuff onto the stack). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message