From patchwork Sun Apr 30 22:26:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Stoakes X-Patchwork-Id: 13227328 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 4859CC77B73 for ; Sun, 30 Apr 2023 22:26:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F8A26B0072; Sun, 30 Apr 2023 18:26:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A91C6B0074; Sun, 30 Apr 2023 18:26:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3221E6B0075; Sun, 30 Apr 2023 18:26:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1F3CF6B0072 for ; Sun, 30 Apr 2023 18:26:45 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C9ADB804AA for ; Sun, 30 Apr 2023 22:26:44 +0000 (UTC) X-FDA: 80739493128.19.F17A5F9 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf06.hostedemail.com (Postfix) with ESMTP id 0C590180007 for ; Sun, 30 Apr 2023 22:26:42 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="UUJ/NDbb"; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682893603; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=okwsBHwtVho9RM+LIvD/U8UT1JGc7W3WT4T39OwkLBE=; b=ZoJPSzEdhS85tAonLVhqUQaPVxcxHc9QmWk1MFKHw6YEy3mzI9TE2LDAa5lDkTsiDPuv+S pfbL8fCeyGCxEEWis06l4V33Fq55ajdi0LyI/J8LBnd46baj9p19U2fEzB1Up7PEu+RTPl okTz/UEucHAMlQKxdU4sRa+sj1HZV/8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="UUJ/NDbb"; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682893603; a=rsa-sha256; cv=none; b=RqKh0pk/cq2r/ZKHEjvf/+8ek3QmpUhM87rrQgbxpTLAcEwwP+UP1OJTyA8fVC7R8PmcIv SW47nvjZt1z8nKklw+Q/xQNCcQ7LWXUUPrIkhISWgiSAUFHYFnntN/3HvAniOkJww3lqZj WOiZWNQ5ek+mOWztcaCp2vf0/+lzD80= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-2f87c5b4635so1749683f8f.1 for ; Sun, 30 Apr 2023 15:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682893601; x=1685485601; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=okwsBHwtVho9RM+LIvD/U8UT1JGc7W3WT4T39OwkLBE=; b=UUJ/NDbbfOsxeA/Q0SOBghVYDteCo9FAjpu2BQuXtF0TZJfU2YQ86MmGpfrHqy6tjp T8+O+Xc74+kvmTbFHtADMkXyeTwapRaBYM3A+cSw/gROkda4aTTmyNNWpEHUsYj/sALL CZsY1WHTwx2Q7YXY+95VXHGq16udXRuUE+5WOpdHjcLO1uP3wfIsRmJVD9elvMj1ePK+ ceGn6AvjANPQIbaEaBoWW/I2UHKK/pUH7YoGqlTPYq+9MgWqxqTn7WGyvY7eeKkGKFJN VV+Krys6lbg97MpHHNsv8Qg5Ktbv6emSyQzgqqkF1M3oge+YH+DV4k5F/9F/+X9dqOQ3 LNlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682893601; x=1685485601; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=okwsBHwtVho9RM+LIvD/U8UT1JGc7W3WT4T39OwkLBE=; b=DJme0VGRhSkOJ7jcBi83UtZuL5a740z0ps7dw25h5pGhiiKd/eO3UyAiLrQhkqo0Aq r0KpdNsChwqgnBVa+ricm8pgj08weBQ6qIasBvNlFeeOkeP91TL8X6C4OYPhFMdTWEKI hUMeuJaoa++DgayAQu8ARmJ7KBVGwyuWmSjYS71TrVsLvafTPdwL/rO1ivcprtL+9AIe P+c9HUMpDlvcPN7Z+K73NxWtqTsZXJ1t+7t8s/BF+L32cBcRCGELSD0iN/suO0uiIzad 5sNDhOvC8gazHzUgCvQmamKR6Hu/dLPux+bDcq8keEPO2bhvQSStSZrw1pn0omquDzpb UIPQ== X-Gm-Message-State: AC+VfDykwLxwIbiimMaz76sMql1gb5gjFe8I/fHD1AaxO1qqD4BtBqYs esXl2u3tgqDT/GRXS0iri4RT3OdEzBOOtQ== X-Google-Smtp-Source: ACHHUZ7y1xuoHHoFogOgEwzy3Gl+4P31trS1M5DtpRjSebq/LaRrngoPfxSiZSLenWWrvGC1U/Py0w== X-Received: by 2002:a05:6000:84:b0:306:2c43:7afc with SMTP id m4-20020a056000008400b003062c437afcmr1386799wrx.34.1682893600876; Sun, 30 Apr 2023 15:26:40 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id g2-20020a5d5402000000b002da75c5e143sm26699865wrv.29.2023.04.30.15.26.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Apr 2023 15:26:40 -0700 (PDT) From: Lorenzo Stoakes To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Matthew Wilcox , Mike Kravetz , Muchun Song , Alexander Viro , Christian Brauner , Andy Lutomirski , linux-fsdevel@vger.kernel.org, Jan Kara , Hugh Dickins , Lorenzo Stoakes Subject: [PATCH v2 0/3] permit write-sealed memfd read-only shared mappings Date: Sun, 30 Apr 2023 23:26:04 +0100 Message-Id: X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0C590180007 X-Stat-Signature: 7djtxfxsztkn5ow6jcxrut8a6c84sdx3 X-Rspam-User: X-HE-Tag: 1682893602-473114 X-HE-Meta: U2FsdGVkX19iSlsdJMVY0NMWPOaDOSzoQHEUJj89u70NXBHDrqU6HmZY3qRVX1s4zRHjMsCRKYeQPv8gC2yjfQYuNjEx9BDM7FmdquoPSTbjwU4rqXsjp9bi5pdv7sxZc9qRU523RMJ0qR10EThMd2vpKF98BuJGyzDF3ohC3HGy4VdAYRlBxm3c3G14sCM3MLMpLEJsvd/ShTrOuMbxOo0ydsAOnHXQbmqHgpHuRWQUYbbjYDGlwRlq1utinv1xtvlqDGRZKZATAwqsjxSk+yAwO6gTW1N7IP+pl/9qg6/1gLhbUDer0mMzWQO0cICyppOqVxhHibNuZPSJaKBQ3mzXhziuhCnSaUtXZ+GNqxFPKpt9u3axH9yiShTUE9mCo/U9JfK6GEz6TGF4Ks3RQHFIyyu7q5odWNRzBdgyord9b0thYoYVYSZNRt9u6kCZI37Wzudg2JvSnOtWGrsBqsPPqcAThE/R1cMZuXnx0ScIwhiowQeQoHduLQCjQSKdw8cdHPgHzUalhmkBf8v8qh3Og4+qm2p+BxxtRXXEdVfUpcJ1VMYtSiEc2k7c0ahUH3tGg/raAkcYxZaAhpIpGBZHkiISwTEwwxbcAF0oQuR/EpPZA+bdvbmZv9ZrhV4ElIWXSsWtY3z+lF6N23GB7gU7oZkwhL4ATkOQ9X+d1PVESqWidkxxP24mkcOaFevEwHgWLYye19YRJ4+qwLShYIy8BAWkSHR5Ek4MGCiGqUP/BAkYtlG55LafRwz1kMGDILywxA0+3b/oo8MbbOSseGu926glENEbeBZplX3MOToX7Q4obNMBJZj/0KPPGSwhHw7zy6d+jqMoiaMT20UpNeT/eRoLav1rz3DaP0hlvgroXYDezopcGXVGaAVBXXNIwr1zE6OKSTWLGQwOcmLg1evw6N1xSZMtMiYzBLY6sO82xI0FvbDsmsvXaPn5G1wlCukYm5b627W4BY7ZhOP a6CfOMMa rXT4QdMpcq4W1h2t7Z48gpxNzgRDIy4Agnr8fFxbkb7tg34JCYjQRhAV1aq6lVvulFhuSd98F0yfbSks3rVgI2ETJNalztsuCqvioQNJVJ/n9nTK/BW/59vuWYli4CemEeQWe8Mh9ywtb2j7+F9LdoL8H5cwVjOc2pA8TQpILuOPp+ku08JhIDtW6/fYIKL7ggdcedeZAQHI+CqQAHQsOwD3nNnjIEQ5fSpXXmtYsxF9O25nEM4m/enaexMI6H/GVUCglJ9JBg0/BqubHSTJbiJm/sZJ8JukkyGYvNVX5NHuhrY/MwnGNbiranxVEp4MXxz8npCNR1WeYZHaJNYeITT6p7xtKUHg6hrbXxwI4Po43gHHCyyyVD1HZi9ZAzKPB3RR4iujZNJLzFQKdC+SqPpOAwi5/QOcSvcOJ2Y6xpVMz/Kr2NkC26cthxKkbwQf96qitEh9HqXamDKzfWV7E5PWTCBNYKro+Btrpw5PlDydtJMHjW41b2KG85jB8A+utk/al 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: The man page for fcntl() describing memfd file seals states the following about F_SEAL_WRITE:- Furthermore, trying to create new shared, writable memory-mappings via mmap(2) will also fail with EPERM. With emphasis on _writable_. In turns out in fact that currently the kernel simply disallows _all_ new shared memory mappings for a memfd with F_SEAL_WRITE applied, rendering this documentation inaccurate. This matters because users are therefore unable to obtain a shared mapping to a memfd after write sealing altogether, which limits their usefulness. This was reported in the discussion thread [1] originating from a bug report [2]. This is a product of both using the struct address_space->i_mmap_writable atomic counter to determine whether writing may be permitted, and the kernel adjusting this counter when _any_ VM_SHARED mapping is performed. It seems sensible that we should only update this mapping if VM_MAYWRITE is specified, i.e. whether it is possible that this mapping could at any point be written to. If we do so then all we need to do to permit write seals to function as documented is to clear VM_MAYWRITE when mapping read-only. It turns out this functionality already exists for F_SEAL_FUTURE_WRITE - we can therefore simply adapt this logic to do the same for F_SEAL_WRITE. The final change required is to invoke call_mmap() before mapping_map_writable() - doing so ensures that the memfd-relevant shmem_mmap() or hugetlbfs_file_mmap() custom mmap handlers will be called before the writable test, enabling us to clear VM_MAYWRITE first. Thanks to Andy Lutomirski for the suggestion! [1]:https://lore.kernel.org/all/20230324133646.16101dfa666f253c4715d965@linux-foundation.org/ [2]:https://bugzilla.kernel.org/show_bug.cgi?id=217238 v2: - Removed RFC tag. - Correct incorrect goto pointed out by Jan. - Reworded cover letter as suggested by Jan. v1: https://lore.kernel.org/all/cover.1680560277.git.lstoakes@gmail.com/ Lorenzo Stoakes (3): mm: drop the assumption that VM_SHARED always implies writable mm: update seal_check_[future_]write() to include F_SEAL_WRITE as well mm: perform the mapping_map_writable() check after call_mmap() fs/hugetlbfs/inode.c | 2 +- include/linux/fs.h | 4 ++-- include/linux/mm.h | 24 ++++++++++++++++++------ kernel/fork.c | 2 +- mm/filemap.c | 2 +- mm/madvise.c | 2 +- mm/mmap.c | 22 +++++++++++----------- mm/shmem.c | 2 +- 8 files changed, 36 insertions(+), 24 deletions(-) --- 2.40.1