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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 DA7A9C4338F for ; Fri, 13 Aug 2021 20:51:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7896960F91 for ; Fri, 13 Aug 2021 20:51:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7896960F91 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C812F6B006C; Fri, 13 Aug 2021 16:51:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C31DB6B0071; Fri, 13 Aug 2021 16:51:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF9218D0001; Fri, 13 Aug 2021 16:51:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 94BB06B006C for ; Fri, 13 Aug 2021 16:51:43 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 35C321C97D for ; Fri, 13 Aug 2021 20:51:43 +0000 (UTC) X-FDA: 78471253686.39.7B2E66D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id CC4B6801AB2A for ; Fri, 13 Aug 2021 20:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628887902; 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: in-reply-to:in-reply-to:references:references; bh=m2X6nzOXxo3H0EdqupppVKuVb2Pe4/bVUTDNmqoeLdE=; b=d9kII7peboPqZKQZlTN3nzT6IV+QsRTJmU4+KnsfpfG9HJoFRs0dsaJlzu1XtvMbUeKVoE t64FBHd9jSqkobwbkNbFg3GEHmYoOMYclKENelNmtWMwrdY0gcsUbZrAYRa6a25nkoFcUF ZfgjIKGOMcGtkIUQacpHiNtZt/iuU0s= 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-458-v1YXj8r7NgSXyByDb11Zdg-1; Fri, 13 Aug 2021 16:51:40 -0400 X-MC-Unique: v1YXj8r7NgSXyByDb11Zdg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EA0855A069; Fri, 13 Aug 2021 20:51:33 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 795DB1BCF0; Fri, 13 Aug 2021 20:51:11 +0000 (UTC) From: Florian Weimer To: ebiederm@xmission.com (Eric W. Biederman) Cc: David Laight , Linus Torvalds , Andy Lutomirski , David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Thomas Gleixner , "Ingo Molnar" , Borislav Petkov , "H. Peter Anvin" , Al Viro , Alexey Dobriyan , Steven Rostedt , "Peter Zijlstra (Intel)" , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , "Namhyung Kim" , Petr Mladek , "Sergey Senozhatsky" , Andy Shevchenko , Rasmus Villemoes , Kees Cook , 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 , Miklos Szeredi , Chengguang Xu , Christian =?utf-8?Q?K=C3=B6nig?= , "linux-unionfs@vger.kernel.org" , Linux API , "the arch/x86 maintainers" , , Linux-MM , "Michael Kerrisk (man-pages)" Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> <87eeay8pqx.fsf@disp2133> <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> Date: Fri, 13 Aug 2021 22:51:09 +0200 In-Reply-To: <87h7ft2j68.fsf@disp2133> (Eric W. Biederman's message of "Fri, 13 Aug 2021 15:17:51 -0500") Message-ID: <871r6xdq6a.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CC4B6801AB2A X-Stat-Signature: 6t3rwdyri5tckqedb9ppggr3xftchgh8 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=d9kII7pe; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf06.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=fweimer@redhat.com X-HE-Tag: 1628887902-271100 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: * Eric W. Biederman: > Florian Weimer, would it be possible to get glibc's ld.so implementation to use > MAP_SHARED? Just so people reading the code know what to expect of the > kernel? As far as I can tell there is not a practical difference > between a read-only MAP_PRIVATE and a read-only MAP_SHARED. Some applications use mprotect to change page protections behind glibc's back. Using MAP_SHARED would break fork pretty badly. Most of the hard-to-diagnose crashes seem to come from global data or relocations because they are wiped by truncation. And we certainly can't use MAP_SHARED for those. Code often seems to come back unchanged after the truncation because the overwritten file hasn't actually changed. File attributes don't help because the copying is an adminstrative action in the context of the application (maybe the result of some automation). I think avoiding the crashes isn't the right approach. What I'd like to see is better diagnostics. Writing mtime and ctime to the core file might help. Or adding a flag to the core file and /proc/PID/smaps that indicates if the file has been truncated across the mapping since the mapping was created. A bit less conservative and even more obvious to diagnose would be a new flag for the mapping (perhaps set via madvise) that causes any future access to the mapping to fault with SIGBUS and a special si_code value after the file has been truncated across the mapping. I think we would set that in the glibc dynamic loader. It would make the crashes much less weird. Thanks, Florian