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 73CFAECAAA1 for ; Wed, 31 Aug 2022 01:18:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF9728D0001; Tue, 30 Aug 2022 21:18:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA84A6B0072; Tue, 30 Aug 2022 21:18:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6FC98D0001; Tue, 30 Aug 2022 21:18:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A4FF36B0071 for ; Tue, 30 Aug 2022 21:18:32 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7CE751605D0 for ; Wed, 31 Aug 2022 01:18:32 +0000 (UTC) X-FDA: 79858127664.24.3995809 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf30.hostedemail.com (Postfix) with ESMTP id 1E5BE80057 for ; Wed, 31 Aug 2022 01:18:31 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id bq23so17899950lfb.7 for ; Tue, 30 Aug 2022 18:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=YdigL9mdfE/0hNS5gRz7RikDbrA/FSPnOXRX8Mw8fQo=; b=h9jRoiN4Z7DMAgNwBStObbVmRqZzodsYOdu4El9wyBAcjq7ZcUcqcvor7F2ZJ6J1xG kV6Ko3b2AE/t7suQuzy8Jx/1KUT8tLjl6ozSbHl7SnXnESVFrRkryFiJa7CGXK5TESV4 T6AD3UeKGi2VUKhbs7imHCHIUgnD5rhV/Op9pGbfC/Tmuua547PmmZW+YDL5L0tmhtfe f67TELVbK7MWXgMR5lcH9F6hgB4Mc87l0KpjfwwurtyO90NBvp46XHZLbJNCJannpIVT iUdxR4+iAkORS8eYebiFuJxKiVN5iRZX9FB8FMt9QTmevJQ0torYb+M7HrvCsuzRHTke FfTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=YdigL9mdfE/0hNS5gRz7RikDbrA/FSPnOXRX8Mw8fQo=; b=LSWOYptHQ08sbPhqIaNcno7r3in8LuNusPgUYazWdkXFKgkcUibp8HLfAmLExQuPTs 9odsstR9Zji9/DTOXBgD0zanhrao6UbxcHRSkdLi0na4R94OApycezOKeEJgexWBF15C l+fqYGsoo5VJqqMKrVDTY1OLyhTe2Dahu8PJkexfB07qeUcvVfM7t3MzDfiGF4wIkolj jK9s702zTAPwdW7LwF5NXOxe9kqTyyKabgPmgy1lhXIV5UnMfZCeJCq14vhp/6751mMT DDiX5VWxi4ZpuSkaC2Y+VL12wqjZZJtBkEgoKejse7tLw+ZaMFjKcVb5ntSbl/MRT51M 4ubw== X-Gm-Message-State: ACgBeo2BjuTqC9RwX/0H7njqWpeF/B31+gMBXWfJYkINpppQbu/KwUQn uFZ+1OIGsxo57r9lcb9rtl/0LGTKhiVc6uiMpX0= X-Google-Smtp-Source: AA6agR6TDH/k8jKRG/W42SD7AuvkaHpSGOxENbANejrv34fgKlkUKpJUDImBnURU/DFc+bEONHVvZWctpz7YP7x5QYA= X-Received: by 2002:ac2:4c4c:0:b0:492:bc29:e328 with SMTP id o12-20020ac24c4c000000b00492bc29e328mr8065768lfk.386.1661908710335; Tue, 30 Aug 2022 18:18:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrei Vagin Date: Tue, 30 Aug 2022 18:18:18 -0700 Message-ID: Subject: Re: Potentially undesirable interactions between vfork() and time namespaces To: Alexey Izbyshev Cc: linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, Christian Brauner , Florian Weimer , linux-mm@kvack.org, Eric Biederman , Kees Cook Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=h9jRoiN4; spf=pass (imf30.hostedemail.com: domain of avagin@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=avagin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661908712; a=rsa-sha256; cv=none; b=A0fSfLNA74cSjTjKJ23NYwt08iwT5P/2IHQqMUkaH3C0JyaEz9k/LJsv/kWoyXN+r1VsyR JMZC6aZes/NozuwtytpcAhmDRorrfFfDRwbZWFW2c0jLi7Mvv/Rb/Cjx0Ye2qecfstL02y N9NKpwJxaZtozac0QRvOpNsLEtljibM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661908712; 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=YdigL9mdfE/0hNS5gRz7RikDbrA/FSPnOXRX8Mw8fQo=; b=CcrNwknBd17rax94Cgo8xPtsKjfGsBUaJjiH21bTYCGn8FEDU1MMl5Jfvhv2oB9Q/oCS6X EcOaq8UCqGtpGjZAa1ErGl3rjwS4jbzY5xDHlu3IWXEgD/1ifF05ggxR6sxiMpNSNgTxy/ YLNbgNJPRPydkfH0CcWE7EUSGcN57ZU= X-Rspam-User: X-Rspamd-Queue-Id: 1E5BE80057 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=h9jRoiN4; spf=pass (imf30.hostedemail.com: domain of avagin@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=avagin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: mhn9uj6az57c7qf73qxgpcdrmcyoz3ir X-Rspamd-Server: rspam08 X-HE-Tag: 1661908711-768542 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, Aug 30, 2022 at 12:49 PM Alexey Izbyshev wrote: > > Hi, > > I've looked at Andrei's patch[1] that permitted vfork() after > unshare(CLONE_NEWTIME) and noticed a couple of odd things that I'd like > to point out. > > /* > * If the new process will be in a different time namespace > * do not allow it to share VM or a thread group with the forking > task. > + * > + * On vfork, the child process enters the target time namespace only > + * after exec. > */ > - if (clone_flags & (CLONE_THREAD | CLONE_VM)) { > + if ((clone_flags & (CLONE_VM | CLONE_VFORK)) == CLONE_VM) { > if (nsp->time_ns != nsp->time_ns_for_children) > return ERR_PTR(-EINVAL); > } > > This change permits not only a normal vfork(), but also > clone(CLONE_VM|CLONE_VFORK|CLONE_SIGHAND|CLONE_THREAD). I'm not sure > whether it can cause real harm, but it's pretty inconsistent to forbid > creation of normal threads after unshare(CLONE_NEWTIME), but permit such > weird ones, so maybe the check should be strengthened. Good catch. I was not aware that CLONE_VFORK is allowed to be used with CLONE_THREAD. I will send a fix. Thanks. > > Also, if such a thread execs, no time namespace switch will happen > because it's vfork_done field will be cleared when its creator (a > sibling thread) is killed by de_thread(). > > + vfork = !!tsk->vfork_done; > old_mm = current->mm; > exec_mm_release(tsk, old_mm); > if (old_mm) > @@ -1030,6 +1033,10 @@ static int exec_mmap(struct mm_struct *mm) > tsk->mm->vmacache_seqnum = 0; > vmacache_flush(tsk); > task_unlock(tsk); > + > + if (vfork) > + timens_on_fork(tsk->nsproxy, tsk); > + > > Similarly, even after a normal vfork(), time namespace switch could be > silently skipped if the parent dies before "tsk->vfork_done" is read. > Again, I don't know whether anybody cares, but this behavior seems > non-obvious and probably unintended to me. This is the more interesting case. I will try to find out how we can handle it properly. Thanks, Andrei