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 84882C77B61 for ; Fri, 28 Apr 2023 17:01:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED9A56B0074; Fri, 28 Apr 2023 13:01:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E87AC6B0075; Fri, 28 Apr 2023 13:01:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D28CF6B0078; Fri, 28 Apr 2023 13:01:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C5EF26B0074 for ; Fri, 28 Apr 2023 13:01:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 985AA802D2 for ; Fri, 28 Apr 2023 17:01:54 +0000 (UTC) X-FDA: 80731416948.05.81AA39A Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf01.hostedemail.com (Postfix) with ESMTP id 839C94003F for ; Fri, 28 Apr 2023 17:01:52 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=p47hnQpC; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.52 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=1682701312; 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=enibV5jjvXXD+9T0mSZmRELNc6TJEPGRaHEL3xkjr4g=; b=aVTvr/hSkPWBS0Ggv2if8vtIPmi7J+L86J7ChsAe4EIBT+JksvM81DdpLLnLeydj7hl9Lp nYO9Xzhh0NbiwniYKN2WS9OzRHDcnKdxzRC4nD+kb8a6c/O+bI2Ah4Cac5k1yAhxdN6QFe ATNseC53+y4qTRPMXokpjGt2oFMKtc8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=p47hnQpC; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.52 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=1682701312; a=rsa-sha256; cv=none; b=rUBWfPBlEpgTrHzh42ve/39p/AlHJTs/AyuItlIbnD6ffen707zQpBW+vTkH8FLsk0/+CA dVgwloO5pLfQkyHs+wmu/2fdpdqMKF4Y9I+itQO/1MknCk4vsEuUyC6iN3xH0we8D805GQ A8OnMyCceZaaUNtpVG+hI8IKr6mNixk= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-3f315735514so69202205e9.1 for ; Fri, 28 Apr 2023 10:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682701311; x=1685293311; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=enibV5jjvXXD+9T0mSZmRELNc6TJEPGRaHEL3xkjr4g=; b=p47hnQpCoSM2raO5h30nylblO+/gxiJKCQD4btAglQ9CVgvJRUjuLfC1c1uxOqpitm FRBmjW/dhR42vlOrBxqJNRzVVCe9g6EsGxHWGaAPdz5a1HWBktWoWwGlnMtLDGxfjr/A 7uozTl4sgpFn1DAWMH4C8Zf71Gs72fKu7Ka6lSUniFHBPCeL4oO86PN2UdaYocqUvhlX xIRTRED2ja+mCxPZ0EkYzvAIgyduZELL7qBLnfsl1i858L/QBFL82SqirmzF7aUZJ7qa oPB2nVQrLvRoweIXd1v34bvYYKOkyOSX3Pa7u2e+4wccJFyYfOmuq0dE2wI/b6zRKcpb tIKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682701311; x=1685293311; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=enibV5jjvXXD+9T0mSZmRELNc6TJEPGRaHEL3xkjr4g=; b=YTY5um935DAQufPGG0LLPVsWDY39s+jsEqVf3aAnBzQpEibnbaIdSyIQdXAKalBhKT GzBs5eN29NpRM7aMLGnANc1Mtlt2st+b0ARXfFZLw6APmxmm4YxFvWJAqK3bI9wHdm3S /iIjQ+BTp1u6qwC4JzfwsWoi/rBWMS0SSIihL+gm4O6CoTWtE8NiIWBGC6c+ma8mIfQ6 ZRmVoz2Rsxc4h+/bjoUTYNvbuC6NQ9z4nv6ZrgaQvgq4FQGN0kya6nzrPD2HWPyZe2hy ep59YNL5gWbBaB/QkFSPn0RWmYDVO/NrGp4T8NJMrSazBOEOg7KTfSgwYsnITBH7a2+R Zibg== X-Gm-Message-State: AC+VfDxLysbQiGlIa5E6o6gCV45NVGQq2BOwOn8T8/zzZelGk0pkoFVp stnUFFwcUEcdxGZ9yY0EnXI= X-Google-Smtp-Source: ACHHUZ5eOFK7TLniTEYeQwmHoBHsJdnADKkJSXPamAdlOt4aeVyQGuBN9SqvNz189bRBjMlijDd4GA== X-Received: by 2002:a05:600c:2281:b0:3f1:72db:454c with SMTP id 1-20020a05600c228100b003f172db454cmr4718172wmf.19.1682701310816; Fri, 28 Apr 2023 10:01:50 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id iv18-20020a05600c549200b003f17b91c3adsm28870445wmb.28.2023.04.28.10.01.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Apr 2023 10:01:50 -0700 (PDT) Date: Fri, 28 Apr 2023 18:01:49 +0100 From: Lorenzo Stoakes To: "Kirill A . Shutemov" Cc: David Hildenbrand , Peter Xu , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , John Hubbard , Jan Kara , Pavel Begunkov , Mika Penttila , David Howells , Christoph Hellwig Subject: Re: [PATCH v5] mm/gup: disallow GUP writing to file-backed mappings by default Message-ID: <3604708a-bf24-4c39-a257-771b93ae70c0@lucifer.local> References: <400da248-a14e-46a4-420a-a3e075291085@redhat.com> <077c4b21-8806-455f-be98-d7052a584259@lucifer.local> <62ec50da-5f73-559c-c4b3-bde4eb215e08@redhat.com> <6ddc7ac4-4091-632a-7b2c-df2005438ec4@redhat.com> <20230428160925.5medjfxkyvmzfyhq@box.shutemov.name> <39cc0f26-8fc2-79dd-2e84-62238d27fd98@redhat.com> <20230428162207.o3ejmcz7rzezpt6n@box.shutemov.name> <173337c0-14f4-3246-15ff-7fbf03861c94@redhat.com> <20230428165623.pqchgi5gtfhxd5b5@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230428165623.pqchgi5gtfhxd5b5@box.shutemov.name> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 839C94003F X-Stat-Signature: tgiw8x1s4c7rrhqhwry3jq3aoyf33368 X-Rspam-User: X-HE-Tag: 1682701312-391430 X-HE-Meta: U2FsdGVkX1+G0/5cVaoF3c4AYmIHUbmO6nF4FanDga4/4UyvOpPxtE32lKzFocEHm5HtvKjfzjdL9uBkH37+ksPRBnhn4bORA1zJbR0vdVCebSJzzfbNoffadl4EApk48wTu0vaiaPahnB9HJECg0GhUYQuJepdd+jDuFzxSgoZvFrXH9VpKWg+b5exH9frXHpkVTW7I2CLyGUU+kjsKMgGb8RWv1NPzVlDg/lVcUoCswveGFN1fBQ+I6wa9ELCc3CKjy65+JLewJNtRtbqFlb0Mjrxlzn8h6V8/N7jsOMq3zS6+9DbZMpye8BXxThLA27bxaz+isms8fH3luVwcOYGfaACO3Y2HpMGlavcZiGyZ898kiRzKrQsnhJ/lQD+nkmsarYtZBi51576LP5f53JaWUYn5pL5uZBENv6/uwqzMtIMFJm8CnGHLEfRQ3icoRpK3Xi7/0aHIO8OqEgl9eT+xdRoqHrZiAUbD6wh1UufHHIY3g1d9vbbcPCIlINy9FDbU98wf+qDlBSBEXur2u8FulJLwvVm/37+rghS3y/ydlwMd5LTOwmkWYAA6Df9BKICJCdUc0yqB9M16URv8BU0pZiLOrFtk1mJ5mo4bW0AffAqs0lVQcTgGGx1fCtXObrq00lXJ2C4x7Oq4Sd3EIRsfzjj8mn0+Ufop9wW/xyGIrZCzqHjWFAuCSVZo8F86U5w0Ufis5cWmO94AT53G499Zt7vS6h3WXX3yYpd3MlQKNMU2AZBior7c9wudgSNAI8GLD07cS4FtLRJs+RNTbLtqidHLt8yQKxEm/iSVVtdGTKAWgVsxDBzUFsUeFubNAf9GMJRwWTHbRkCUG/8BZuUWT4UeLNO1ZYsXsOZ4YvK+KvBn74GH5UnGCLH7+aABhaMrZwiSdmdNXR3D2UCo+4twweGKkqnlQVEXlbBZPtbftXTJsWgk/94xu37MMGQbnLdgVm3NvSbVOINob1W bESFpzcz 7PM3iBUV7l4ifjuIHbltVvqIDsFy1la1FWxchiJhm6MhxhYY5fV4Z8RVdqwoLq3DhgKFrP/oPxriID/QdZfEvGqQf2pD1l7u9h0dQtWdcSztHKGM5CYO1auz48QAp/1xPGTSpdqHyc4g1Y7zoRE7qx7o9yCzp2QABn16k0ACdoW/EJTWH1kKA+wXvcB/lqs/GDJP4VGjW9Nsd42sZM+DKspqyLQHtrPEG9XuXibpXguNLaimSs423lM2/afgGNwTUszYncd/7VT17siU7DU5tA2DtwL3zJvw4A/kvwQc5QNcBYQZ8BDD9ziHClNwUQdWmYSoZtskagOrJAuU69v7ootJuMdcJ6u/yzTqDoj4gvQu9cz87oZQ0Mm4KKFQorG9FNj0Kn0OEY8LUdqSOf2keoWnksKOqAOSw92tWTb2mKjMgr66nGI6u671qT8u+fN0bG534TOBUQaAX9/22zdy7mHWI3A== 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, Apr 28, 2023 at 07:56:23PM +0300, Kirill A . Shutemov wrote: > On Fri, Apr 28, 2023 at 06:51:46PM +0200, David Hildenbrand wrote: > > On 28.04.23 18:39, Peter Xu wrote: > > > On Fri, Apr 28, 2023 at 07:22:07PM +0300, Kirill A . Shutemov wrote: > > > > On Fri, Apr 28, 2023 at 06:13:03PM +0200, David Hildenbrand wrote: > > > > > On 28.04.23 18:09, Kirill A . Shutemov wrote: > > > > > > On Fri, Apr 28, 2023 at 05:43:52PM +0200, David Hildenbrand wrote: > > > > > > > On 28.04.23 17:34, David Hildenbrand wrote: > > > > > > > > On 28.04.23 17:33, Lorenzo Stoakes wrote: > > > > > > > > > On Fri, Apr 28, 2023 at 05:23:29PM +0200, David Hildenbrand wrote: > > > > > > > > > > > > > > > > > > > > > > > > Security is the primary case where we have historically closed uAPI > > > > > > > > > > > > items. > > > > > > > > > > > > > > > > > > > > > > As this patch > > > > > > > > > > > > > > > > > > > > > > 1) Does not tackle GUP-fast > > > > > > > > > > > 2) Does not take care of !FOLL_LONGTERM > > > > > > > > > > > > > > > > > > > > > > I am not convinced by the security argument in regard to this patch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we want to sells this as a security thing, we have to block it > > > > > > > > > > > *completely* and then CC stable. > > > > > > > > > > > > > > > > > > > > Regarding GUP-fast, to fix the issue there as well, I guess we could do > > > > > > > > > > something similar as I did in gup_must_unshare(): > > > > > > > > > > > > > > > > > > > > If we're in GUP-fast (no VMA), and want to pin a !anon page writable, > > > > > > > > > > fallback to ordinary GUP. IOW, if we don't know, better be safe. > > > > > > > > > > > > > > > > > > How do we determine it's non-anon in the first place? The check is on the > > > > > > > > > VMA. We could do it by following page tables down to folio and checking > > > > > > > > > folio->mapping for PAGE_MAPPING_ANON I suppose? > > > > > > > > > > > > > > > > PageAnon(page) can be called from GUP-fast after grabbing a reference. > > > > > > > > See gup_must_unshare(). > > > > > > > > > > > > > > IIRC, PageHuge() can also be called from GUP-fast and could special-case > > > > > > > hugetlb eventually, as it's table while we hold a (temporary) reference. > > > > > > > Shmem might be not so easy ... > > > > > > > > > > > > page->mapping->a_ops should be enough to whitelist whatever fs you want. > > > > > > > > > > > > > > > > The issue is how to stabilize that from GUP-fast, such that we can safely > > > > > dereference the mapping. Any idea? > > > > > > > > > > At least for anon page I know that page->mapping only gets cleared when > > > > > freeing the page, and we don't dereference the mapping but only check a > > > > > single flag stored alongside the mapping. Therefore, PageAnon() is fine in > > > > > GUP-fast context. > > > > > > > > What codepath you are worry about that clears ->mapping on pages with > > > > non-zero refcount? > > > > > > > > I can only think of truncate (and punch hole). READ_ONCE(page->mapping) > > > > and fail GUP_fast if it is NULL should be fine, no? > > > > > > > > I guess we should consider if the inode can be freed from under us and the > > > > mapping pointer becomes dangling. But I think we should be fine here too: > > > > VMA pins inode and VMA cannot go away from under GUP. > > > > > > Can vma still go away if during a fast-gup? > > > > > > > So, after we grabbed the page and made sure the the PTE didn't change (IOW, > > the PTE was stable while we processed it), the page can get unmapped (but > > not freed, because we hold a reference) and the VMA can theoretically go > > away (and as far as I understand, nothing stops the file from getting > > deleted, truncated etc). > > > > So we might be looking at folio->mapping and the VMA is no longer there. > > Maybe even the file is no longer there. > > No. VMA cannot get away before PTEs are unmapped and TLB is flushed. And > TLB flushing is serialized against GUP_fast(). > But the lockless path doesn't hold the PTL? So PTE can disappear at anytime, since we use ptep_get_lockless(). But it won't matter because then the fast path will just fail anyway and can revert back to slow one. > -- > Kiryl Shutsemau / Kirill A. Shutemov