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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85D04C7618E for ; Mon, 24 Apr 2023 12:19:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05B006B0071; Mon, 24 Apr 2023 08:19:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00ACB6B0074; Mon, 24 Apr 2023 08:19:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEDA56B0075; Mon, 24 Apr 2023 08:19:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CE7FA6B0071 for ; Mon, 24 Apr 2023 08:19:41 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 995E6A0182 for ; Mon, 24 Apr 2023 12:19:41 +0000 (UTC) X-FDA: 80716190562.30.5C880F5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 518B416001C for ; Mon, 24 Apr 2023 12:19:39 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=U8Ap4Bg2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LaPP5aHf; dmarc=none; spf=pass (imf08.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682338779; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tH3QxEeyp8kfWcz1bkYSovs9h7ImBxkgM1DNmDxhaJg=; b=nxOjtjf/OxOHDBqEOpjQXyPyYjyVRLFe/y342OAExf5PhXP6ckcWw692sv7UXNYQiL4EFm OnaPqQvvtFJgwu2zbCkbWacXbOUlQQXVyVw/B1kGjcvHaWWlI3Q/Y7PkoKzJtv2A9eGIq0 RlIXfu+uRQvKtWXaG6m0NTdeAUamAKM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=U8Ap4Bg2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LaPP5aHf; dmarc=none; spf=pass (imf08.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682338779; a=rsa-sha256; cv=none; b=r3NF3q3s8Gan0GKIsn/vioz5seMu/Ta7NZeC8XC97bBN6MPtEj4eO+BDbGTMA3o68h+o2u 0pYRUX0kPxc7kSkov5L/W5yxB1lhs2fesBGODG2K27Jv3lxj2OE3IPEDl3j0BAYQfLvyv2 eh1AeS6EULPd34DZnYQzyF+4gvE5Z7c= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7A0D81FD80; Mon, 24 Apr 2023 12:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1682338777; h=from:from:reply-to: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=tH3QxEeyp8kfWcz1bkYSovs9h7ImBxkgM1DNmDxhaJg=; b=U8Ap4Bg2ocGY4N9KLmdiXJ3k3RWwRz6oUO8RZlNHZWwp0un0OpL64bHpI1g3fOxb1woAsH ItgJw2Cfz+eEX4qrSxeIJ7TV4vEFeRG35WWd4R2qNqdsQhU9eLdW3kEbVVo4ns/APWjmbp zt0Ccr2Eo51bBlJsa3aempb+/gVFX88= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1682338777; h=from:from:reply-to: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=tH3QxEeyp8kfWcz1bkYSovs9h7ImBxkgM1DNmDxhaJg=; b=LaPP5aHf+gTxAxLtBoghtsddhF6BkLYkqb8AtLbjILPSAiTl5h9wfxFQ0tRi14O8X+GOMN 4joBTRBV5KJviMCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6B2B21390E; Mon, 24 Apr 2023 12:19:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 3kogGtlzRmTzcAAAMHmgww (envelope-from ); Mon, 24 Apr 2023 12:19:37 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id E8A34A0729; Mon, 24 Apr 2023 14:19:36 +0200 (CEST) Date: Mon, 24 Apr 2023 14:19:36 +0200 From: Jan Kara To: Lorenzo Stoakes Cc: Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Matthew Wilcox , Mike Kravetz , Muchun Song , Alexander Viro , Christian Brauner , Andy Lutomirski Subject: Re: [RFC PATCH 0/3] permit write-sealed memfd read-only shared mappings Message-ID: <20230424121936.lwgqty6hifs7eecp@quack3> References: <20230421090126.tmem27kfqamkdaxo@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 518B416001C X-Stat-Signature: sizq54qw3amnx38ruxha44jxgqsjeas1 X-HE-Tag: 1682338779-149276 X-HE-Meta: U2FsdGVkX1/kg3VnpP35OKWuhemr4VuYM7IORpKalspN1kR3J0DwxWfv7J8Cx+j1CvyzgYlWqekzAh8KZ8q39I6LBVKj62+rW29vDB1IZj2Y2b0BpbUzVuTnw/gffWP4nkbc5VhcUDPvD7IGBFgT2bcDv8A81MxotCUkR4xPlIR9Cfp1SnLocFTyWKYXs8/05gPJKyrnGReIVGERLJCtdMIqeS+MmjgpNexhKtHsCetkFHX7PPDzxSjN98aCdfb/zQB9zMzqGaunYBROKb0srCDmRyXa004AOBdqndGESN0gRwe2VF9VbJjjYNs1gKPPJNbYXWGXqO2UxFPWdkRwjlZlUTAhFLJvxGAWGGQVw9gML8vCgyavmMBeHzptFi2TvgMhQZLo5JeGgt4VMx70/0MEn9Nz7JuOJI7FQrTCMu7tLjQDhJiwSC0j5X2VbF3I5scEGE/1pDcSGFOc3X7N4hkXkhfmIFogv6C9W7/I1YHGbQdrwH8ev6ESksYF6KN9pZ8mBl+V67IHmOhtwC8VHAdv3mebfrQkLHMEMymmdYg3L/w9l44CPKvcrKeMvU634t/WY6pDUNpg0rJ72GzbUZtMXXGM2ElC/93xEZ2Z8CmHV7MmkRY5oM/K3y4pHpTnJEC5qycyXv3mfEba+Zw9W1w27OWafvnRyna8bLTz2pDifFJrgNnB6oqbQoEicjI/G7FXb6MiIrTJcQ8REI7ZUUImL3ezvWW5xw61+GK58pxPc1d5xfzCvA8bprBixHZC9NjlAsLJ96pBxHNutxpra4ibMONJtZWnPasXtXvQubOpb5TqzqnNc740g9GpoM6Qe1q4rVSu2nm5t6eFEsqNSJE4zWCEwNKuMvFXIevabp0uiDJO0QgdWYJYRNra0f5gD4esiizlwq9TfPyyir7Nu8b6cazi0nFuNfYBnAadsOEno6EPPDRzXkotI5zqe91wV4QmXhD3JB5tUc5kIDN khrvbm0H IG6gyyMajZEgRN5OIqPJkoDwbwxCgFuIdq7Skb/fwd0Bkvm4RRbX9MaAmMEFbT5V1al66r1Vp88oDAxCK62FlyomjQlbvNoH88AENIm2ZuUqNd8+Z4Yxah/KuKVPqR56obFcVTrN81LL1blKZYRiEmlzOrMMhnKDZqhk2o3RBbACq9G/S72ZymZeqpZe6DUTj+ATBaEZiF9m1snGMzbduMya1W4MwLS38WFa95ZsPCq5KfwHU5E/bRq+2XXMX6gn+MUkv 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: On Fri 21-04-23 22:23:12, Lorenzo Stoakes wrote: > On Fri, Apr 21, 2023 at 11:01:26AM +0200, Jan Kara wrote: > > Hi! > > > > On Mon 03-04-23 23:28:29, Lorenzo Stoakes wrote: > > > This patch series is in two parts:- > > > > > > 1. Currently there are a number of places in the kernel where we assume > > > VM_SHARED implies that a mapping is writable. Let's be slightly less > > > strict and relax this restriction in the case that VM_MAYWRITE is not > > > set. > > > > > > This should have no noticeable impact as the lack of VM_MAYWRITE implies > > > that the mapping can not be made writable via mprotect() or any other > > > means. > > > > > > 2. Align the behaviour of F_SEAL_WRITE and F_SEAL_FUTURE_WRITE on mmap(). > > > The latter already clears the VM_MAYWRITE flag for a sealed read-only > > > mapping, we simply extend this to F_SEAL_WRITE too. > > > > > > For this to have effect, we must also invoke call_mmap() before > > > mapping_map_writable(). > > > > > > As this is quite a fundamental change on the assumptions around VM_SHARED > > > and since this causes a visible change to userland (in permitting read-only > > > shared mappings on F_SEAL_WRITE mappings), I am putting forward as an RFC > > > to see if there is anything terribly wrong with it. > > > > So what I miss in this series is what the motivation is. Is it that you need > > to map F_SEAL_WRITE read-only? Why? > > > > This originated from the discussion in [1], which refers to the bug > reported in [2]. Essentially the user is write-sealing a memfd then trying > to mmap it read-only, but receives an -EPERM error. > > F_SEAL_FUTURE_WRITE _does_ explicitly permit this but F_SEAL_WRITE does not. > > The fcntl() man page states: > > Furthermore, trying to create new shared, writable memory-mappings via > mmap(2) will also fail with EPERM. > > So the kernel does not behave as the documentation states. > > I took the user-supplied repro and slightly modified it, enclosed > below. After this patch series, this code works correctly. > > I think there's definitely a case for the VM_MAYWRITE part of this patch > series even if the memfd bits are not considered useful, as we do seem to > make the implicit assumption that MAP_SHARED == writable even if > !VM_MAYWRITE which seems odd. Thanks for the explanation! Could you please include this information in the cover letter (perhaps in a form of a short note and reference to the mailing list) for future reference? Thanks! Honza -- Jan Kara SUSE Labs, CR