From patchwork Fri Apr 23 13:16:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 12220367 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=-8.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 E35CBC43460 for ; Fri, 23 Apr 2021 13:17:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 566A961445 for ; Fri, 23 Apr 2021 13:17:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 566A961445 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 32DC56B00D4; Fri, 23 Apr 2021 09:17:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B6956B00D5; Fri, 23 Apr 2021 09:17:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E3546B00D6; Fri, 23 Apr 2021 09:17:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id DB5C36B00D4 for ; Fri, 23 Apr 2021 09:17:10 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 99174180DC46F for ; Fri, 23 Apr 2021 13:17:10 +0000 (UTC) X-FDA: 78063682620.33.FBFFD5E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 0E8502000380 for ; Fri, 23 Apr 2021 13:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619183829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=u7WjucWMKhco5a0xvZlF0gB5mBL6gDa1ouYEA5LycDs=; b=WDUSJSqknDfV1fOKN6jBwbVF3qwsLc6vxMDzCz7HryL8E4ls5j+hqMJxIzG4+f4XmqYwbU a5HhBtINLEgfBG+wzgCY0OMj4Z+Hc5C7bUc3Y2tXbgPmKraI2IlMszH9PxlTdN23rnTuBn 387R00so8gQy+SwoAtOu6+w20OJuCCo= 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-163-a3otH4XROmi4zXbJq7JOCA-1; Fri, 23 Apr 2021 09:17:07 -0400 X-MC-Unique: a3otH4XROmi4zXbJq7JOCA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B29F480D6A8; Fri, 23 Apr 2021 13:17:00 +0000 (UTC) Received: from t480s.redhat.com (ovpn-112-41.ams2.redhat.com [10.36.112.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 76CF360C13; Fri, 23 Apr 2021 13:16:41 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: David Hildenbrand , 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 , Christian Brauner , Jens Axboe , Gabriel Krisman Bertazi , Peter Xu , Suren Baghdasaryan , Shakeel Butt , Marco Elver , Daniel Jordan , Nicolas Viennot , Thomas Cedeno , Collin Fijalkovich , Michal Hocko , linux-api@vger.kernel.org, x86@kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH RFC 0/7] Remove in-tree usage of MAP_DENYWRITE Date: Fri, 23 Apr 2021 15:16:33 +0200 Message-Id: <20210423131640.20080-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0E8502000380 X-Stat-Signature: 9xnwknyynpxjosuahgxhuj11f74asobj Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619183831-949988 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: This series is based on [1] [PATCH v1 0/3] perf/binfmt/mm: remove in-tree usage of MAP_EXECUTABLE and [2] [PATCH v2] mm, thp: Relax the VM_DENYWRITE constraint on file-backed THPs This series removes all in-tree usage of MAP_DENYWRITE from the kernel and removes VM_DENYWRITE. We stopped supporting MAP_DENYWRITE for user space applications a while ago because of the chance for DoS. The last renaming user is binfmt binary loading during exec and legacy library loading via uselib(). With this change, MAP_DENYWRITE is effectively ignored throughout the kernel. Although the net change is small, I think the cleanup in mmap() is quite nice. There are some (minor) user-visible changes with this series, that's why I am flagging this as RFC and cc-ing linux-api: 1. We no longer deny write access to shared libaries loaded via legacy uselib(); this behavior matches modern user space e.g., via dlopen(). 2. We no longer deny write access to the elf interpreter after exec completed, treating it just like shared libraries (which it often is). 3. We always deny write access to the file linked via /proc/pid/exe: sys_prctl(PR_SET_MM_EXE_FILE) will fail if write access to the file cannot be denied, and write access to the file will remain denied until the link is effectivel gone (exec, termination, PR_SET_MM_EXE_FILE) -- just as if exec'ing the file. I was wondering if we really care about permanently disabling write access to the executable, or if it would be good enough to just disable write access while loading the new executable during exec; but I don't know the history of that -- and it somewhat makes sense to deny write access at least to the main executable. With modern user space -- dlopen() -- we can effectively modify the content of shared libraries while being used. I'm not 100% sure if the race documented in patch #3 applies (forking while another thread is doing a PR_SET_MM_EXE_FILE), but I assume this is possible. [1] https://lkml.kernel.org/r/20210421093453.6904-1-david@redhat.com [2] https://lkml.kernel.org/r/20210406000930.3455850-1-cfijalkovich@google.com Cc: Andrew Morton Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Alexander Viro Cc: Alexey Dobriyan Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Mark Rutland Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Kees Cook Cc: "Eric W. Biederman" Cc: Greg Ungerer Cc: Geert Uytterhoeven Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Vincenzo Frascino Cc: Chinwen Chang Cc: Michel Lespinasse Cc: Catalin Marinas Cc: "Matthew Wilcox (Oracle)" Cc: Huang Ying Cc: Jann Horn Cc: Feng Tang Cc: Kevin Brodsky Cc: Michael Ellerman Cc: Shawn Anastasio Cc: Steven Price Cc: Nicholas Piggin Cc: Christian Brauner Cc: Jens Axboe Cc: Gabriel Krisman Bertazi Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Shakeel Butt Cc: Marco Elver Cc: Daniel Jordan Cc: Nicolas Viennot Cc: Thomas Cedeno Cc: Collin Fijalkovich Cc: Michal Hocko Cc: linux-api@vger.kernel.org Cc: x86@kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-mm@kvack.org David Hildenbrand (7): binfmt: don't use MAP_DENYWRITE when loading shared libraries via uselib() kernel/fork: factor out atomcially replacing the current MM exe_file kernel/fork: always deny write access to current MM exe_file binfmt: remove in-tree usage of MAP_DENYWRITE mm: remove VM_DENYWRITE mm: ignore MAP_DENYWRITE in ksys_mmap_pgoff() fs: update documentation of get_write_access() and friends arch/x86/ia32/ia32_aout.c | 8 ++-- fs/binfmt_aout.c | 7 ++-- fs/binfmt_elf.c | 6 +-- fs/binfmt_elf_fdpic.c | 2 +- fs/proc/task_mmu.c | 1 - include/linux/fs.h | 19 +++++---- include/linux/mm.h | 3 +- include/linux/mman.h | 4 +- include/trace/events/mmflags.h | 1 - kernel/events/core.c | 2 - kernel/fork.c | 75 ++++++++++++++++++++++++++++++---- kernel/sys.c | 33 +-------------- lib/test_printf.c | 5 +-- mm/mmap.c | 29 ++----------- mm/nommu.c | 2 - 15 files changed, 98 insertions(+), 99 deletions(-)