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=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 3F53DC43214 for ; Sat, 14 Aug 2021 09:06:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 183276103A for ; Sat, 14 Aug 2021 09:06:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237639AbhHNJHX (ORCPT ); Sat, 14 Aug 2021 05:07:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:52804 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237547AbhHNJHW (ORCPT ); Sat, 14 Aug 2021 05:07:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628932013; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sWOfJKXDv3Msrm1oZtxU2+iL1w42iciVMe2lnnbOuSA=; b=IZudabC6+PPKpDqUUOvvZ8dNb0ZZBvTXwtNN1eK/zdOLkV7WwFpgEehA1U9kQXE/KMxvRK Pa0/2FXyk6+l3bfTbadv7MmXUvepD3Oj16xecsMatS/gcuhPDvaZBuX0NTZrp14Ac/qqRm LBe+MbT7T4FJVXp5e0CyArPy4R8hLNE= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-531-p4R7xtDcMNiNjxZczC_Zeg-1; Sat, 14 Aug 2021 05:06:52 -0400 X-MC-Unique: p4R7xtDcMNiNjxZczC_Zeg-1 Received: by mail-wr1-f71.google.com with SMTP id p2-20020a5d48c20000b0290150e4a5e7e0so3546996wrs.13 for ; Sat, 14 Aug 2021 02:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sWOfJKXDv3Msrm1oZtxU2+iL1w42iciVMe2lnnbOuSA=; b=Fb7Y+0flpLPckfr5VSzgsHYLSgECxaNfyIx09kEKL+h7rGCGD/iK5peAk7+NdYMvzI SbVa2P8CVRB2pf7JlDS/DLZrZNy3VVNquQ39etlqWWXfe71gGfXPJU0Mv6HP+oJzeo24 l7LhEVvLf8jAuEayLWQnHJq5/Kp/Nde24sa3mM0DfLQMjOq+kgbsGz4W/WDcZKY8g8bu nbzgqkkph+WT8AYyaHCs/4kptJy+gT0idpi8AWX0dLUQq28xDHBXTu3m+2GoVDFyXJHI N1m7JV/FovwPFCoi832uY207+B/qKrk3GttmfN5bF8/3soY8IqRNOE5uMVoyCcLOdW6U J2Nw== X-Gm-Message-State: AOAM530wXJ9ZZTWUkP/igvnRHuPFALkkQ1hpRd0XsHVo4sC6n6lTP2pv NMQK7+428BdP3lN438rlx7rs/I8TUkRSNpmb5K29yh0BrvOXyznMzExoQzBbbcJMhbiwOggH8yU OK8oPsxOBDinq4JT1yj/pIQODXg== X-Received: by 2002:a1c:3b09:: with SMTP id i9mr6361382wma.62.1628932011324; Sat, 14 Aug 2021 02:06:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmRQCvf+Z+ORlo8pa+7ajUFCHPEEEB/g8t9ifOo/hJh3Qa3/emogzOCEyiSbKRsyYXp+6DPg== X-Received: by 2002:a1c:3b09:: with SMTP id i9mr6361322wma.62.1628932011053; Sat, 14 Aug 2021 02:06:51 -0700 (PDT) Received: from [192.168.3.132] (p4ff2325a.dip0.t-ipconnect.de. [79.242.50.90]) by smtp.gmail.com with ESMTPSA id l9sm3846322wrt.95.2021.08.14.02.06.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 02:06:50 -0700 (PDT) To: Al Viro , Linus Torvalds Cc: Andy Lutomirski , "Eric W. Biederman" , David Laight , Linux Kernel Mailing List , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , 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@vger.kernel.org, Linux-MM , Florian Weimer , Michael Kerrisk References: <87lf56bllc.fsf@disp2133> <87eeay8pqx.fsf@disp2133> <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE Message-ID: Date: Sat, 14 Aug 2021 11:06:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 14.08.21 04:02, Al Viro wrote: > On Sat, Aug 14, 2021 at 01:57:31AM +0000, Al Viro wrote: >> On Fri, Aug 13, 2021 at 02:58:57PM -1000, Linus Torvalds wrote: >>> On Fri, Aug 13, 2021 at 2:54 PM Linus Torvalds >>> wrote: >>>> >>>> And nobody really complained when we weakened it, so maybe removing it >>>> entirely might be acceptable. >>> >>> I guess we could just try it and see... Worst comes to worst, we'll >>> have to put it back, but at least we'd know what crazy thing still >>> wants it.. >> >> Umm... I'll need to go back and look through the thread, but I'm >> fairly sure that there used to be suckers that did replacement of >> binary that way (try to write, count on exclusion with execve while >> it's being written to) instead of using rename. Install scripts >> of weird crap and stuff like that... > > ... and before anyone goes off - I certainly agree that using that > behaviour is not a good idea and had never been one. All I'm saying > is that there at least used to be very random (and rarely exercised) > bits of userland relying upon that behaviour. > Removing it completely is certainly more controversial than limiting it to the main executable. I'm mostly happy as long as we get rid of that nasty per-VMA handling, because that adds real complexity at places that are complicated enough. Having the remaining deny_write_access()/allow_write_access() at sane places now (loading a new binary, exchanging exe_file) looks certainly much cleaner and I still consider it a valuable, simple sanity feature to have around. I don't think there is any sane use case for modifying the main executable, and it seems to be very easy to catch. For example, besides users that rely on this behavior, in my thinking (see the cover letter), especially having a binary not getting changed while we're loading it sounds like a very good idea (not saying we would expose a way to exploit the kernel if we would allow for modifications while in the elf parser, but also not saying we wouldn't because I didn't check if there would be a way; at least we already allow it in the legacy library loader before mapping the segments with MAP_DENYWRITE). And if we decide to keep the behavior while loading the executable, keeping it while exe_file is set isn't much added code/complexity IMHO. Long story short, I'd vote for keeping it in, and if we decide to rip it out completely, do it a a separate, more careful step. -- Thanks, David / dhildenb