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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E965DC43334 for ; Wed, 15 Jun 2022 07:52:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BBB76B0071; Wed, 15 Jun 2022 03:52:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 844AB6B0072; Wed, 15 Jun 2022 03:52:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BE646B0073; Wed, 15 Jun 2022 03:52:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5742B6B0071 for ; Wed, 15 Jun 2022 03:52:27 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 266F612135F for ; Wed, 15 Jun 2022 07:52:27 +0000 (UTC) X-FDA: 79579702734.27.30C2467 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 7B50840005 for ; Wed, 15 Jun 2022 07:52:26 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6F2FA618AC; Wed, 15 Jun 2022 07:52:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED225C3411C; Wed, 15 Jun 2022 07:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655279544; bh=/Cq8JxWDGWPl1V210SZ7wqDAk1YugafyAPEyJX3tbh4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WbXfnxamMI9lriVQxFHGz+SDHAV/InUwRvxz9w+8yPYsVUbPEZC9X+nw40fofM1jP dNldOC17X30lLDafgiwlqAUgKqjfYVUwcJxgj9fpSlPBquLHfAvEWSENSW/MV/BnjW TbJmhDmNRRDEc7U0TuIMkgQqxdadP+3msiO+mwmn+BXhqQ253EIxokGRNJfD6QkNWV ieGANqzWz677uZiaLRBiahDa+Wz7y+gFcv+WF5gpf1dm6765hDMARgcG8e6N+1knT4 wjMHUUPuVNfktVIJM/m3X0rHPSzaNb+xHMjnwkLQopi1DvZwS/Wc52y8HvzsUXiWLi LcsRhjzywnBnQ== Date: Wed, 15 Jun 2022 09:52:19 +0200 From: Christian Brauner To: Kees Cook Cc: Andrei Vagin , linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, Florian Weimer , linux-mm@kvack.org, Eric Biederman Subject: Re: [PATCH 1/2] fs/exec: allow to unshare a time namespace on vfork+exec Message-ID: <20220615075219.5cvoc3py3zdm74oo@wittgenstein> References: <20220613060723.197407-1-avagin@gmail.com> <202206141412.2B0732FF6C@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202206141412.2B0732FF6C@keescook> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655279546; a=rsa-sha256; cv=none; b=6zk/37POvQd9FaqYouKBZu7P5nZ1sT6EEPIc4Fv3bWrH8b8fYT0f6I/vX4Dw/QHDMDGzok 5RXJqiXIVTqsB0eYCrgvgWuU6AqzRclpE/QfJu4nMlvC1hqx9r1vYUzh5PZrlhaN3Gnnq7 6ioTivPjrlgqNo6oo389CV4Wbo+yIX4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WbXfnxam; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655279546; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4YCosIekAOS/OZL39QeFYiAZW3CIYaBg4tcyQmnY8Iw=; b=dt5nfBnzx6Gzkk7K+M/9zqAxv+oxySvyMa/IHeH71CUOHBHcncF5rjVWrej0huSjeRZjmo Gi53NJ6KW7kVnTFXsujnu6dABWoAtyQVm02/i3zQFH7Cyu1lqWtYwFVfHkaOQX0Fhr2Mrd K2pMuDcG65atAa1Ia2cL+HXdCrkg1b8= Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WbXfnxam; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org X-Rspam-User: X-Stat-Signature: 1sxq1su1zzn1gfbtsr8uith1heguumgf X-Rspamd-Queue-Id: 7B50840005 X-Rspamd-Server: rspam08 X-HE-Tag: 1655279546-954073 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 14, 2022 at 02:14:35PM -0700, Kees Cook wrote: > On Sun, Jun 12, 2022 at 11:07:22PM -0700, Andrei Vagin wrote: > > Right now, a new process can't be forked in another time namespace > > if it shares mm with its parent. It is prohibited, because each time > > namespace has its own vvar page that is mapped into a process address > > space. > > > > When a process calls exec, it gets a new mm and so it could be "legal" > > to switch time namespace in that case. This was not implemented and > > now if we want to do this, we need to add another clone flag to not > > break backward compatibility. > > > > We don't have any user requests to switch times on exec except the > > vfork+exec combination, so there is no reason to add a new clone flag. > > As for vfork+exec, this should be safe to allow switching timens with > > the current clone flag. Right now, vfork (CLONE_VFORK | CLONE_VM) fails > > if a child is forked into another time namespace. With this change, > > vfork creates a new process in parent's timens, and the following exec > > does the actual switch to the target time namespace. > > This seems like a very special case. None of the other namespaces do > this, do they? > > How is CLONE_NEWTIME supposed to be used today? Time namespaces are similar to pid namespaces. If a process calls unshare(CLONE_NEWTIME) it will not change into a new time namespace. Only the children of the process will. You can also see this via /proc//ns/time and /proc//ns/time_for_children. After an unshare(CLONE_NEWTIME) /proc//ns/time will be unchanged while /proc//ns/time_for_children will reference a new time namespace. So if the process now calls fork() the child will be placed in a new time namespace. As Andrei correctly points out in the commit message each time namespace gets it's own vvar page mapped into the process address space. Consequently calls to clone*() with CLONE_VM will need to fail because it would alter the parent's mm as well. That includes vfork() which is roughly just CLONE_VM | CLONE_VFORK. fork() remains unaffected. So anything that implements a process launcher using vfork() needs to implement a fork() fallback after vfork failure() in case the original process has unshared a new time namespace. As posix spawn is implemented using vfork() we would force glibc to implement a fork() fallback and enforce the introducing of a lot of complexity to work around this. I think the proposal here makes sense and allows us to avoid introducing yet another clone flag. For vfork() it also makes sense because the calling process is suspended until exec or exit so the semantics between fork() and clone*() are sufficiently distinct to justify this difference. Iow, vfork() is distinctly targeted at enforcing an exec* call already anyway. Christian