From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 207DAC43331 for ; Mon, 11 Nov 2019 15:20:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EAB4C2184C for ; Mon, 11 Nov 2019 15:20:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZYzyx+8k" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726953AbfKKPUx (ORCPT ); Mon, 11 Nov 2019 10:20:53 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:53271 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726857AbfKKPUw (ORCPT ); Mon, 11 Nov 2019 10:20:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573485651; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1zGHKvwpfTIUGcapQ+PDyzQUKdMx+4TB/qV51A6KfM=; b=ZYzyx+8k88KApyTDKgLQLPjMrXkY7WyCLfrmL/wRjCWkjU8JvFLNWHAJkTZD/zHZiIl7Iw +XxcFy7n0nk+RxKe7hwqCJgp34FqP8OF+at4RI2KxovGN5f0oLakv4emNRoZasZiS9p+0f FSe0q/hoN0YdnxkwXqv3eAtuQ8c5cyk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-6-vBGvGzzCMIG6kes1J63o-g-1; Mon, 11 Nov 2019 10:20:48 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6F7F5911AD; Mon, 11 Nov 2019 15:20:46 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-200.str.redhat.com [10.33.192.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2E6F060852; Mon, 11 Nov 2019 15:20:38 +0000 (UTC) From: Florian Weimer To: Jann Horn Cc: "Michael Kerrisk \(man-pages\)" , Christian Brauner , lkml , linux-man , Kees Cook , Oleg Nesterov , Arnd Bergmann , David Howells , Pavel Emelyanov , Andrew Morton , Adrian Reber , Andrei Vagin , Linux API Subject: Re: For review: documentation of clone3() system call References: <87tv7awj4g.fsf@oldenburg2.str.redhat.com> Date: Mon, 11 Nov 2019 16:20:36 +0100 In-Reply-To: (Jann Horn's message of "Mon, 11 Nov 2019 16:15:58 +0100") Message-ID: <875zjqwibf.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: vBGvGzzCMIG6kes1J63o-g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jann Horn: > On Mon, Nov 11, 2019 at 4:03 PM Florian Weimer wrote= : >> >> * Michael Kerrisk: >> >> > Another difference for the raw clone() system call is that = the >> > stack argument may be NULL, in which case the child uses a dup= li=E2=80=90 >> > cate of the parent's stack. (Copy-on-write semantics ensure t= hat >> > the child gets separate copies of stack pages when either proc= ess >> > modifies the stack.) In this case, for correct operation, = the >> > CLONE_VM option should not be specified. (If the child shares = the >> > parent's memory because of the use of the CLONE_VM flag, then= no >> > copy-on-write duplication occurs and chaos is likely to result.= ) >> >> I think sharing the stack also works with CLONE_VFORK with CLONE_VM, as >> long as measures are taken to preserve the return address in a register. > > That basically just requires that the userspace function declaration > for clone3 includes __attribute__((returns_twice)), right? The clone3 implementation itself would have to store the return address in a register because at the time of the second return, a return address on the stack may have been corrupted by the subprocess because what used to be the stack frame of the clone function has since been reused for something else. __attribute__ ((returns_twice)) is likely needed as well, but that benefits the caller. It's also not clear that it is sufficient for this to work in all cases. (But the mandatory-to-implement vfork function faces the same problems.) Thanks, Florian