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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 15A0FC4320A for ; Thu, 12 Aug 2021 12:32:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 599386109D for ; Thu, 12 Aug 2021 12:32:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 599386109D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C7CFB6B0073; Thu, 12 Aug 2021 08:32:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C06446B0074; Thu, 12 Aug 2021 08:32:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA6D28D0002; Thu, 12 Aug 2021 08:32:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 8A51F6B0073 for ; Thu, 12 Aug 2021 08:32:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 371F48249980 for ; Thu, 12 Aug 2021 12:32:56 +0000 (UTC) X-FDA: 78466367952.24.430951C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP id A641C100DA8A for ; Thu, 12 Aug 2021 12:32:55 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1D1E560724; Thu, 12 Aug 2021 12:32:41 +0000 (UTC) Date: Thu, 12 Aug 2021 14:32:39 +0200 From: Christian Brauner To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Alexander Viro , Alexey Dobriyan , Steven Rostedt , Peter Zijlstra , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Petr Mladek , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Kees Cook , "Eric W. Biederman" , Greg Ungerer , Geert Uytterhoeven , Mike Rapoport , Vlastimil Babka , Vincenzo Frascino , Chinwen Chang , Michel Lespinasse , Catalin Marinas , "Matthew Wilcox (Oracle)" , Huang Ying , Jann Horn , Feng Tang , Kevin Brodsky , Michael Ellerman , Shawn Anastasio , Steven Price , Nicholas Piggin , Jens Axboe , Gabriel Krisman Bertazi , Peter Xu , Suren Baghdasaryan , Shakeel Butt , Marco Elver , Daniel Jordan , Nicolas Viennot , Thomas Cedeno , Collin Fijalkovich , Michal Hocko , Miklos Szeredi , Chengguang Xu , Christian =?utf-8?B?S8O2bmln?= , linux-unionfs@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Andrei Vagin Subject: Re: [PATCH v1 3/7] kernel/fork: always deny write access to current MM exe_file Message-ID: <20210812123239.trksnm57owzwzokj@wittgenstein> References: <20210812084348.6521-1-david@redhat.com> <20210812084348.6521-4-david@redhat.com> <20210812100544.uhsfp75b4jcrv3qx@wittgenstein> <1b6d27cf-2238-0c1c-c563-b38728fbabc2@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1b6d27cf-2238-0c1c-c563-b38728fbabc2@redhat.com> Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of "SRS0=0fOM=ND=ubuntu.com=christian.brauner@kernel.org" designates 198.145.29.99 as permitted sender) smtp.mailfrom="SRS0=0fOM=ND=ubuntu.com=christian.brauner@kernel.org"; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A641C100DA8A X-Stat-Signature: une4bnuatx5ztmmeoqbzegw56x1fhcyq X-HE-Tag: 1628771575-415423 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 Thu, Aug 12, 2021 at 12:13:44PM +0200, David Hildenbrand wrote: > On 12.08.21 12:05, Christian Brauner wrote: > > [+Cc Andrei] > > > > On Thu, Aug 12, 2021 at 10:43:44AM +0200, David Hildenbrand wrote: > > > We want to remove VM_DENYWRITE only currently only used when mapping the > > > executable during exec. During exec, we already deny_write_access() the > > > executable, however, after exec completes the VMAs mapped > > > with VM_DENYWRITE effectively keeps write access denied via > > > deny_write_access(). > > > > > > Let's deny write access when setting the MM exe_file. With this change, we > > > can remove VM_DENYWRITE for mapping executables. > > > > > > This represents a minor user space visible change: > > > sys_prctl(PR_SET_MM_EXE_FILE) can now fail if the file is already > > > opened writable. Also, after sys_prctl(PR_SET_MM_EXE_FILE), the file > > > > Just for completeness, this also affects PR_SET_MM_MAP when exe_fd is > > set. > > Correct. > > > > > > cannot be opened writable. Note that we can already fail with -EACCES if > > > the file doesn't have execute permissions. > > > > > > Signed-off-by: David Hildenbrand > > > --- > > > > The biggest user I know and that I'm involved in is CRIU which heavily > > uses PR_SET_MM_MAP (with a fallback to PR_SET_MM_EXE_FILE on older > > kernels) during restore. Afair, criu opens the exe fd as an O_PATH > > during dump and thus will use the same flag during restore when > > opening it. So that should be fine. > > Yes. > > > > > However, if I understand the consequences of this change correctly, a > > problem could be restoring workloads that hold a writable fd open to > > their exe file at dump time which would mean that during restore that fd > > would be reopened writable causing CRIU to fail when setting the exe > > file for the task to be restored. > > If it's their exe file, then the existing VM_DENYWRITE handling would have > forbidden these workloads to open the fd of their exe file writable, right? Yes. > At least before doing any PR_SET_MM_MAP/PR_SET_MM_EXE_FILE. But that should > rule out quite a lot of cases we might be worried about, right? Yes, it rules out the most obvious cases. The problem is really just that we don't know how common weirder cases are. But that doesn't mean we shouldn't try and risk it. This is a nice cleanup and playing /proc/self/exe games isn't super common. > > > > > Which honestly, no idea how many such workloads exist. (I know at least > > of runC and LXC need to sometimes reopen to rexec themselves (weird bug > > to protect against attacking the exe file) and thus re-open > > /proc/self/exe but read-only.) > > > > > kernel/fork.c | 39 ++++++++++++++++++++++++++++++++++----- > > > 1 file changed, 34 insertions(+), 5 deletions(-) > > > > > > diff --git a/kernel/fork.c b/kernel/fork.c > > > index 6bd2e52bcdfb..5d904878f19b 100644 > > > --- a/kernel/fork.c > > > +++ b/kernel/fork.c > > > @@ -476,6 +476,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > > > { > > > struct vm_area_struct *mpnt, *tmp, *prev, **pprev; > > > struct rb_node **rb_link, *rb_parent; > > > + struct file *exe_file; > > > int retval; > > > unsigned long charge; > > > LIST_HEAD(uf); > > > @@ -493,7 +494,10 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > > > mmap_write_lock_nested(mm, SINGLE_DEPTH_NESTING); > > > /* No ordering required: file already has been exposed. */ > > > - RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm)); > > > + exe_file = get_mm_exe_file(oldmm); > > > + RCU_INIT_POINTER(mm->exe_file, exe_file); > > > + if (exe_file) > > > + deny_write_access(exe_file); > > > mm->total_vm = oldmm->total_vm; > > > mm->data_vm = oldmm->data_vm; > > > @@ -638,8 +642,13 @@ static inline void mm_free_pgd(struct mm_struct *mm) > > > #else > > > static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) > > > { > > > + struct file *exe_file; > > > + > > > mmap_write_lock(oldmm); > > > - RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm)); > > > + exe_file = get_mm_exe_file(oldmm); > > > + RCU_INIT_POINTER(mm->exe_file, exe_file); > > > + if (exe_file) > > > + deny_write_access(exe_file); > > > mmap_write_unlock(oldmm); > > > return 0; > > > } > > > @@ -1163,11 +1172,19 @@ void set_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file) > > > */ > > > old_exe_file = rcu_dereference_raw(mm->exe_file); > > > - if (new_exe_file) > > > + if (new_exe_file) { > > > get_file(new_exe_file); > > > + /* > > > + * exec code is required to deny_write_access() successfully, > > > + * so this cannot fail > > > + */ > > > + deny_write_access(new_exe_file); > > > + } > > > rcu_assign_pointer(mm->exe_file, new_exe_file); > > > - if (old_exe_file) > > > + if (old_exe_file) { > > > + allow_write_access(old_exe_file); > > > fput(old_exe_file); > > > + } > > > } > > > int atomic_set_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file) > > > @@ -1194,10 +1211,22 @@ int atomic_set_mm_exe_file(struct mm_struct *mm, struct file *new_exe_file) > > > } > > > /* set the new file, lockless */ > > > + ret = deny_write_access(new_exe_file); > > > + if (ret) > > > + return -EACCES; > > > get_file(new_exe_file); > > > + > > > old_exe_file = xchg(&mm->exe_file, new_exe_file); > > > - if (old_exe_file) > > > + if (old_exe_file) { > > > + /* > > > + * Don't race with dup_mmap() getting the file and disallowing > > > + * write access while someone might open the file writable. > > > + */ > > > + mmap_read_lock(mm); > > > + allow_write_access(old_exe_file); > > > fput(old_exe_file); > > > + mmap_read_unlock(mm); > > > + } > > > return 0; > > > } > > > -- > > > 2.31.1 > > > > > > > > -- > Thanks, > > David / dhildenb >