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 67F8DC77B60 for ; Fri, 28 Apr 2023 04:21:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CC346B0071; Fri, 28 Apr 2023 00:21:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8556A6B0072; Fri, 28 Apr 2023 00:21:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A7D36B0074; Fri, 28 Apr 2023 00:21:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 54A216B0071 for ; Fri, 28 Apr 2023 00:21:14 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2021340150 for ; Fri, 28 Apr 2023 04:21:14 +0000 (UTC) X-FDA: 80729500068.26.E6A6962 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 76EC340002 for ; Fri, 28 Apr 2023 04:21:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QGUiAcKg; spf=pass (imf12.hostedemail.com: domain of mpenttil@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpenttil@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682655672; a=rsa-sha256; cv=none; b=6mlp/Jt+2dNKEDl29ux3otNXyzsN8YPlxEVkWuzQu7Wbjj/W/rwoy1VpUjQuBpKoKlhMaF NNa9EraTRjD50Uo3rTbwN7DxQUyEBrl4EzNCNW0DiB7PzxEYYoc0XdDvZTSYsvj2GXr5cB yqpISo64UeT0kV0barVbO7WZiTctbdQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QGUiAcKg; spf=pass (imf12.hostedemail.com: domain of mpenttil@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpenttil@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682655672; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HUpymbe2RGMA86yPaoLtY13w/BGrFU5diMfKlivoc0Q=; b=ib89Vt50Xd+zQDnOMe3gUXyCIy9+Cz8V7oT8NVBVXwXPp8Q+2wf1zIMgk/ChtWATUER57F P53B2HLI1fYLESosAdhqROnzPyUWAVLljzvJ6H/AGy5RNz5ByAvIvPi59tw2aw/bVxGv68 KZP1nK03a7Z9ZAcizorVDmUUK2+BTqI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682655670; 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=HUpymbe2RGMA86yPaoLtY13w/BGrFU5diMfKlivoc0Q=; b=QGUiAcKgR8rRzEofNB2zJi5OJ5aeJz0B/ZFghU8niLpgU61m7YHPaPNxaiIr/slqRH4Qy5 LXmgvT02Qq69o8g0ZbkFgkRDCeRb5PMoPyk1798oDkIuvVpB3mijvbhBCl3qoau9R4lAe8 oGyhpMkxaC2QGMaVKmKWsfIPIS7T0Dk= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-481-r6JN7gqXM1qJKQhEo7w09A-1; Fri, 28 Apr 2023 00:21:08 -0400 X-MC-Unique: r6JN7gqXM1qJKQhEo7w09A-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-4f00d3f91a3so4096423e87.0 for ; Thu, 27 Apr 2023 21:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682655667; x=1685247667; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HUpymbe2RGMA86yPaoLtY13w/BGrFU5diMfKlivoc0Q=; b=IX+3BrChVj7rJKoS4EqW2/urinBNGgALgzLlghavjujV/P75+awD56mb5eM9JEUuCc pU4fD8onXzTxu0B/gm4MCpIkn9MIYvYilp8ZEbUncg6/1OyAFNoQUhaeOGVgGWlRGXPd C8eCS6NtguEy4mTBe3qfY+BRYdvrqd5TDzt34Na0frxo5C/swwzBwxUgtXaLHEDTtbEc Wjv0AMyM50qx84lkkS4sfSjQSBneadVvk3CIIhY8+EXc3+oL1b1gnzii0djXYwvRHdRB ROiQ20Eam3N1lXQ9/1YYj7YmPeKks413PlUWwMAhGW26Dp5YwR8Wy5p1JRUSXJLt/r8q V/lw== X-Gm-Message-State: AC+VfDyCo2p+IZGDj6M2uq0t7opG7IkB1ITF6sCmxXg6vWD0ZJQq7/B5 ZjJ6Z1c1cyo//BE2oXKJ5tAjxwXjeJALLDyhbBHZrel3KlXIMYwSGweigdSMQ/C1VCA1KO8OXDp qC+BSqYP+xA== X-Received: by 2002:a2e:9f05:0:b0:2ab:2c7c:507f with SMTP id u5-20020a2e9f05000000b002ab2c7c507fmr1057089ljk.15.1682655667270; Thu, 27 Apr 2023 21:21:07 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4xYYyesjptJcHcm8yBwlV8SIBaW191/q6NabvCec2b1etZ3S1kKdDOZy7gcBfgds3uQvPBSw== X-Received: by 2002:a2e:9f05:0:b0:2ab:2c7c:507f with SMTP id u5-20020a2e9f05000000b002ab2c7c507fmr1057046ljk.15.1682655666887; Thu, 27 Apr 2023 21:21:06 -0700 (PDT) Received: from [192.168.1.121] (85-23-48-202.bb.dnainternet.fi. [85.23.48.202]) by smtp.gmail.com with ESMTPSA id j21-20020a2e8255000000b002ab0d1c9412sm1953021ljh.139.2023.04.27.21.21.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Apr 2023 21:21:06 -0700 (PDT) Message-ID: <3024df40-4c20-867d-8b88-b32aaa04501d@redhat.com> Date: Fri, 28 Apr 2023 07:21:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v5] mm/gup: disallow GUP writing to file-backed mappings by default To: Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Jason Gunthorpe , 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 , Jason Gunthorpe , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov References: <6b73e692c2929dc4613af711bdf92e2ec1956a66.1682638385.git.lstoakes@gmail.com> From: =?UTF-8?Q?Mika_Penttil=c3=a4?= In-Reply-To: <6b73e692c2929dc4613af711bdf92e2ec1956a66.1682638385.git.lstoakes@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 76EC340002 X-Rspamd-Server: rspam01 X-Stat-Signature: cru31brw48rq8xh44f3xdijrt8ewks1i X-HE-Tag: 1682655671-931483 X-HE-Meta: U2FsdGVkX1+ZalnsZ5FCSTJJFZ/LnwRpaWXvuvcWqKbWdmSy3mndO7ZHrCWuB7wI7UgpfQstslEa9b6pEZdekhnBu73ZfvIhtflapvJH5igYyozuDGy9crQ/BSkCSn0BW/5wp/RYa+tR6og248hkKpS7Bs3AiIFvUboIjKd9Q8sOhhcxnHFj9+nNzoi6GawH5d0NMHl5Y3CA+IaWFRj5asYrJv0vAUf79Eg5ih6VenlXZRsomnZQ0Y9uYTj4OWTh6GDk6rLDKngCPIVKYsBqgYA9TSJW3yFoUS8GiJa1Wwm+9Jhm8e6fQ42hqqRsADG49ZXvMxel75y5+4ej1aNSghjmS/DjejnLGTAjMs9inQPl2Xmok/f+wIKTBLdsz01v8f2WPdOOh6v0ko66R7bNfUmw4tySNBQgxBtlBc6qUW5ekvTns7OOrWeMfn8VysP6Pbv8yxv9A4ebu9PPV6ouiKvfun9N8TxrkwcgbC5zJHDLIUcmV7wJRIIxTg2mhRjs8drgPtBXwHybinSeyoTT7ntmyqO3d0cHePV+gUec3PGLZfcN/foEeF8igE8lW7zHYkAf55jpYfMdpW1X1wCdFyop4KzyBE9ckPAF9+2Kf7sx8qATaHH1Zwufy7ngvhrR9XXqY0T1cjB99BFwCZLRMlKKKDkwA+LBnFq7R56tIah3h072o+dRkSASwOX21pZ4Gby2tn5RchGNWikq02B6pfVkbRH8wta3P1gfWWJp4gXhv9Mog1C0iDuyEND3khdM7bdcZpKGf+usLzgZwfEqDUp8ejSB9c7PghtG/Cjw069rt4PyPuz6pbZlHn/1/3VBeIYA8CRzYIH8HpACUwmLMTHBaUkyQw9EpHKl2W2Q5lgsFK4kriA9xTT4ODl0nd9M/n9dDQ4EQZEUwPIwY+a/51lPoG9ORPV5trWdLCPDP5Gw2RIF4lduUfzc4d4vYI5zPlgN5y8pG+UY/ReNZQV bIa/P2fV J4BdM+I2Vve7PTMMAnTcZ1aRhFjiDk/4ogvz+NJT9y9onKHw2A4VvJ3oo0qdiuhtABT89V05n692XfHdZ4HJloZqYzawFdolX3ssEIDgNMeS9ukDgUDzK3ODhfjJi9/E5T2CUpIZSs7PeQHtl/eYK2xy56AP3XaVRcxi6Sas4uWh8VRghte+BBGs7iRkiDk/62W0ZPLju6cirOXPKTAWGGlOt6uasvopP2aEVvdagCKx4D2pi8gJrB4d1UGl41Qhg9WEED1+LDWnjRB/1WxejPDobqlfAnz1DdyGOSNQvLDDOd+MPxDBEutQRFsXq9KtUFg4yweQgDOxjAO7QYbsMXOKXbKFguDmUTcNkxnoTEKV+qDvwqoBCC0ddJKgG78sUxeiZRshFQgrLltjQ/IE00OThQq9VwkwdYAcZh2CfNO41ZfG7jl/yqLr9OcwfXPuC6xZpqUae7Za0qALmm2ID15udc2uw+GU539jf4P14SXWD58NrS/A8Y8vixYJo4txZM26TiderfUXT/9WA5svtFTxu9uy7XfQCPGfcaoqK9ONz4+5aujeHLq1Y7TfVjxyzYMGD/SKwQ+DBZTBGnpXrm6qJfg== 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 28.4.2023 2.42, Lorenzo Stoakes wrote: > Writing to file-backed mappings which require folio dirty tracking using > GUP is a fundamentally broken operation, as kernel write access to GUP > mappings do not adhere to the semantics expected by a file system. > > A GUP caller uses the direct mapping to access the folio, which does not > cause write notify to trigger, nor does it enforce that the caller marks > the folio dirty. > > The problem arises when, after an initial write to the folio, writeback > results in the folio being cleaned and then the caller, via the GUP > interface, writes to the folio again. > > As a result of the use of this secondary, direct, mapping to the folio no > write notify will occur, and if the caller does mark the folio dirty, this > will be done so unexpectedly. > > For example, consider the following scenario:- > > 1. A folio is written to via GUP which write-faults the memory, notifying > the file system and dirtying the folio. > 2. Later, writeback is triggered, resulting in the folio being cleaned and > the PTE being marked read-only. > 3. The GUP caller writes to the folio, as it is mapped read/write via the > direct mapping. > 4. The GUP caller, now done with the page, unpins it and sets it dirty > (though it does not have to). > > This results in both data being written to a folio without writenotify, and > the folio being dirtied unexpectedly (if the caller decides to do so). > > This issue was first reported by Jan Kara [1] in 2018, where the problem > resulted in file system crashes. > > This is only relevant when the mappings are file-backed and the underlying > file system requires folio dirty tracking. File systems which do not, such > as shmem or hugetlb, are not at risk and therefore can be written to > without issue. > > Unfortunately this limitation of GUP has been present for some time and > requires future rework of the GUP API in order to provide correct write > access to such mappings. > > However, for the time being we introduce this check to prevent the most > egregious case of this occurring, use of the FOLL_LONGTERM pin. > > These mappings are considerably more likely to be written to after > folios are cleaned and thus simply must not be permitted to do so. > > As part of this change we separate out vma_needs_dirty_tracking() as a > helper function to determine this which is distinct from > vma_wants_writenotify() which is specific to determining which PTE flags to > set. > > [1]:https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz/ > > Suggested-by: Jason Gunthorpe > Signed-off-by: Lorenzo Stoakes > --- > include/linux/mm.h | 1 + > mm/gup.c | 41 ++++++++++++++++++++++++++++++++++++++++- > mm/mmap.c | 36 +++++++++++++++++++++++++++--------- > 3 files changed, 68 insertions(+), 10 deletions(-) > Thanks Lorenzo for the added patch descriptions! Reviewed-by: Mika Penttilä > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 37554b08bb28..f7da02fc89c6 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2433,6 +2433,7 @@ extern unsigned long move_page_tables(struct vm_area_struct *vma, > #define MM_CP_UFFD_WP_ALL (MM_CP_UFFD_WP | \ > MM_CP_UFFD_WP_RESOLVE) > > +bool vma_needs_dirty_tracking(struct vm_area_struct *vma); > int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot); > static inline bool vma_wants_manual_pte_write_upgrade(struct vm_area_struct *vma) > { > diff --git a/mm/gup.c b/mm/gup.c > index 1f72a717232b..d36a5db9feb1 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -959,16 +959,51 @@ static int faultin_page(struct vm_area_struct *vma, > return 0; > } > > +/* > + * Writing to file-backed mappings which require folio dirty tracking using GUP > + * is a fundamentally broken operation, as kernel write access to GUP mappings > + * do not adhere to the semantics expected by a file system. > + * > + * Consider the following scenario:- > + * > + * 1. A folio is written to via GUP which write-faults the memory, notifying > + * the file system and dirtying the folio. > + * 2. Later, writeback is triggered, resulting in the folio being cleaned and > + * the PTE being marked read-only. > + * 3. The GUP caller writes to the folio, as it is mapped read/write via the > + * direct mapping. > + * 4. The GUP caller, now done with the page, unpins it and sets it dirty > + * (though it does not have to). > + * > + * This results in both data being written to a folio without writenotify, and > + * the folio being dirtied unexpectedly (if the caller decides to do so). > + */ > +static bool writeable_file_mapping_allowed(struct vm_area_struct *vma, > + unsigned long gup_flags) > +{ > + /* If we aren't pinning then no problematic write can occur. */ > + if (!(gup_flags & (FOLL_GET | FOLL_PIN))) > + return true; > + > + /* We limit this check to the most egregious case - a long term pin. */ > + if (!(gup_flags & FOLL_LONGTERM)) > + return true; > + > + /* If the VMA requires dirty tracking then GUP will be problematic. */ > + return vma_needs_dirty_tracking(vma); > +} > + > static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > { > vm_flags_t vm_flags = vma->vm_flags; > int write = (gup_flags & FOLL_WRITE); > int foreign = (gup_flags & FOLL_REMOTE); > + bool vma_anon = vma_is_anonymous(vma); > > if (vm_flags & (VM_IO | VM_PFNMAP)) > return -EFAULT; > > - if (gup_flags & FOLL_ANON && !vma_is_anonymous(vma)) > + if ((gup_flags & FOLL_ANON) && !vma_anon) > return -EFAULT; > > if ((gup_flags & FOLL_LONGTERM) && vma_is_fsdax(vma)) > @@ -978,6 +1013,10 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > return -EFAULT; > > if (write) { > + if (!vma_anon && > + !writeable_file_mapping_allowed(vma, gup_flags)) > + return -EFAULT; > + > if (!(vm_flags & VM_WRITE)) { > if (!(gup_flags & FOLL_FORCE)) > return -EFAULT; > diff --git a/mm/mmap.c b/mm/mmap.c > index 536bbb8fa0ae..7b6344d1832a 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1475,6 +1475,31 @@ SYSCALL_DEFINE1(old_mmap, struct mmap_arg_struct __user *, arg) > } > #endif /* __ARCH_WANT_SYS_OLD_MMAP */ > > +/* Do VMA operations imply write notify is required? */ > +static bool vm_ops_needs_writenotify(const struct vm_operations_struct *vm_ops) > +{ > + return vm_ops && (vm_ops->page_mkwrite || vm_ops->pfn_mkwrite); > +} > + > +/* > + * Does this VMA require the underlying folios to have their dirty state > + * tracked? > + */ > +bool vma_needs_dirty_tracking(struct vm_area_struct *vma) > +{ > + /* Does the filesystem need to be notified? */ > + if (vm_ops_needs_writenotify(vma->vm_ops)) > + return true; > + > + /* Specialty mapping? */ > + if (vma->vm_flags & VM_PFNMAP) > + return false; > + > + /* Can the mapping track the dirty pages? */ > + return vma->vm_file && vma->vm_file->f_mapping && > + mapping_can_writeback(vma->vm_file->f_mapping); > +} > + > /* > * Some shared mappings will want the pages marked read-only > * to track write events. If so, we'll downgrade vm_page_prot > @@ -1484,14 +1509,13 @@ SYSCALL_DEFINE1(old_mmap, struct mmap_arg_struct __user *, arg) > int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot) > { > vm_flags_t vm_flags = vma->vm_flags; > - const struct vm_operations_struct *vm_ops = vma->vm_ops; > > /* If it was private or non-writable, the write bit is already clear */ > if ((vm_flags & (VM_WRITE|VM_SHARED)) != ((VM_WRITE|VM_SHARED))) > return 0; > > /* The backer wishes to know when pages are first written to? */ > - if (vm_ops && (vm_ops->page_mkwrite || vm_ops->pfn_mkwrite)) > + if (vm_ops_needs_writenotify(vma->vm_ops)) > return 1; > > /* The open routine did something to the protections that pgprot_modify > @@ -1511,13 +1535,7 @@ int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot) > if (userfaultfd_wp(vma)) > return 1; > > - /* Specialty mapping? */ > - if (vm_flags & VM_PFNMAP) > - return 0; > - > - /* Can the mapping track the dirty pages? */ > - return vma->vm_file && vma->vm_file->f_mapping && > - mapping_can_writeback(vma->vm_file->f_mapping); > + return vma_needs_dirty_tracking(vma); > } > > /* > -- > 2.40.0 >