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=-5.7 required=3.0 tests=BAYES_00,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 154AAC4338F for ; Thu, 12 Aug 2021 18:10:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E01E761019 for ; Thu, 12 Aug 2021 18:10:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237237AbhHLSLR (ORCPT ); Thu, 12 Aug 2021 14:11:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbhHLSLP (ORCPT ); Thu, 12 Aug 2021 14:11:15 -0400 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98C9DC061756 for ; Thu, 12 Aug 2021 11:10:49 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id n6so11757351ljp.9 for ; Thu, 12 Aug 2021 11:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kMjoLlvtmb7mlrSdQknNJvuiNoe+cD5cNxWCgcmURzw=; b=fAel4ZlqluiDbK7XT2TN285OpKL/k74SaHM+ukhLXBOh8aUgDoAGzVcLvAOBNcLwL7 LW/VCMiZKL3GYhssOvLPpOPnx2NT/Qr4lb/26QY9QP4lDZrSUO3zX9NqiJlhGgoC6/lS /Ep9k9BaQCUABA+deLmcEAO5Iol8v4ErYRRpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kMjoLlvtmb7mlrSdQknNJvuiNoe+cD5cNxWCgcmURzw=; b=a2Mni5vwbr3PCG+tnxa9LCI/gTAFni5h0ZnJAblNujXi663Riuo7v60Zje6rjwxTWX SSgDAe+oScoxe6F+Ob8zrYJ8HMcr1RALZOhj0Rfif+rEAt/3fCCnOkUcDkawhUtET++C GCpPSL2nhUWF6G4rDlPHa1sJFXljj8jOEkFMLEOs8pIP7Or8zpPs/HKX9nJV6tk5rjfe 4xcGhw83SRd5jWSRVmeZd9d5geifP88xe2Xq9tDMcWyN6UFxMr7l7zGIzqHQNoGEwTq/ BZUlbk+sEBER1R2Wm4PkGvKNfS7F/SQ10eQQcyeE5QpeR6fntyb6LnUk8EMA6pn8WZQz 1l7Q== X-Gm-Message-State: AOAM533ZkK8poOKkOMy3c2Bk85dorl1zoI9LlYprP0+8SbAVmhEpSeVM VelQDOf50AC4QdYJGVr99N3hNq0vOI82UarjemQ= X-Google-Smtp-Source: ABdhPJxRlky8uL1FmziS0cMAr7engRIetcxfrX7ltuyYKSevwqsugfiQuQvq8At376d5CbGRnWH2HA== X-Received: by 2002:a05:651c:883:: with SMTP id d3mr3782504ljq.17.1628791847538; Thu, 12 Aug 2021 11:10:47 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id h17sm327859lfr.287.2021.08.12.11.10.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 11:10:45 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id g30so15049970lfv.4 for ; Thu, 12 Aug 2021 11:10:44 -0700 (PDT) X-Received: by 2002:a05:6512:2091:: with SMTP id t17mr3426901lfr.253.1628791844375; Thu, 12 Aug 2021 11:10:44 -0700 (PDT) MIME-Version: 1.0 References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> In-Reply-To: <87lf56bllc.fsf@disp2133> From: Linus Torvalds Date: Thu, 12 Aug 2021 08:10:28 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE To: "Eric W. Biederman" Cc: 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 , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-unionfs@vger.kernel.org, Linux API , "the arch/x86 maintainers" , linux-fsdevel , Linux-MM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 12, 2021 at 7:48 AM Eric W. Biederman wrote: > > Given that MAP_PRIVATE for shared libraries is our strategy for handling > writes to shared libraries perhaps we just need to use MAP_POPULATE or a > new related flag (perhaps MAP_PRIVATE_NOW) No. That would be horrible for the usual bloated GUI libraries. It might help some (dynamic page faults are not cheap either), but it would hurt a lot. This is definitely a "if you overwrite a system library while it's being used, you get to keep both pieces" situation. The kernel ETXTBUSY thing is purely a courtesy feature, and as people have noticed it only really works for the main executable because of various reasons. It's not something user space should even rely on, it's more of a "ok, you're doing something incredibly stupid, and we'll help you avoid shooting yourself in the foot when we notice". Any distro should make sure their upgrade tools don't just truncate/write to random libraries executables. And if they do, it's really not a kernel issue. This patch series basically takes this very historical error return, and simplifies and clarifies the implementation, and in the process might change some very subtle corner case (unmapping the original executable entirely?). I hope (and think) it wouldn't matter exactly because this is a "courtesy error" rather than anything that a sane setup would _depend_ on, but hey, insane setups clearly exist. Linus