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 59FD2C432BE for ; Sat, 14 Aug 2021 09:06:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4005160EFE for ; Sat, 14 Aug 2021 09:06:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237632AbhHNJHX (ORCPT ); Sat, 14 Aug 2021 05:07:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:60748 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237543AbhHNJHW (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-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-531-czsDxzwaMmiykjjkHJIj3g-1; Sat, 14 Aug 2021 05:06:52 -0400 X-MC-Unique: czsDxzwaMmiykjjkHJIj3g-1 Received: by mail-wr1-f72.google.com with SMTP id w1-20020adf8bc10000b0290154bed98988so3599082wra.1 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=aTQWo/rfo/YprG/ayieivlU5qLZgAd1qudfiN8I7uJFygUjxe1yMtFrnxkMleAloQm lPL4hTDIYmcstsqi9Tl6+sr1KZNB+l2C5ExB05CCJGIGqjQ0r4GDuOwUyMYO1jaZvSPf p7lwhApKW3J1wU67QCQmrN9p6opg+o4/yHQUBGta7l90dx7QNf7zOaKx1luWR9IbW9zd KMiKUaP0QGyi2zlqUAVJYW6w8iILKt8OyaRMhsWj4e0stJOBhkLfxyR/fQv2dQHFsSk1 jMYn6PYKIgU1kKdcve8dd92uPlQfHDDTbMLemmg+oayhEurHR3srzfYhezzT9YAJM8Mh cO+w== X-Gm-Message-State: AOAM533gp5cCiUyvSQkYvm93jOvMn/n1kFxhq0dmk2vNhPXJJfosWrx8 y8I++CTZ35SwTPIQNFjQFNkUkvnIUF3UtCN0k+ck4zEHotUEbPLxBFq5XzTpaUeQu0povfnnlby 75mBOJFnykkS7+u77/kBfUA6UrA== X-Received: by 2002:a1c:3b09:: with SMTP id i9mr6361332wma.62.1628932011278; 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-unionfs@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