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 0772CC77B73 for ; Wed, 26 Apr 2023 03:18:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4406F6B0071; Tue, 25 Apr 2023 23:18:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C8BC6B0072; Tue, 25 Apr 2023 23:18:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 268D86B0074; Tue, 25 Apr 2023 23:18:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 110106B0071 for ; Tue, 25 Apr 2023 23:18:47 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C29AC12010B for ; Wed, 26 Apr 2023 03:18:46 +0000 (UTC) X-FDA: 80722085052.07.7449A6E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 640D480006 for ; Wed, 26 Apr 2023 03:18:44 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JeHFBCZj; spf=pass (imf02.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=1682479124; a=rsa-sha256; cv=none; b=cLaxHjgTm6UkKKPD0l+Qa8OYG4JSLtwBQ613g+xlYZLadgPxnebKlCTKxon/yYPJqQ6a5z l/4lLYGJO3SFoyy7PKyJ9lrpN0feCqH9sJnqcDUZfZriGGiqaP5kmELXDyLOyfc7xDcIr/ 4P3n8TQviHLljWRgIevIzNcvGw85qsY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JeHFBCZj; spf=pass (imf02.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=1682479124; 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=KtkS8QZe/o00VB0DHK7QzgrrGugl8akH2mYVPDK5a8k=; b=1KNwOPzNUH38qNqo7PLvqJUENWYTkAVqS1llDUtc20aFXrp2hIaW8pSKKZBOO+VlTZlp2p mBQn/Qit2xZkzbqPmBHHY6HTxVFEf56N80tckSZwHCQtdH3StMPKEjq8DxOfZwPm5bxHvk 1G+XFiQGFFyX48gLSqFxcCe/D69X040= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682479123; 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=KtkS8QZe/o00VB0DHK7QzgrrGugl8akH2mYVPDK5a8k=; b=JeHFBCZjGRbl9WVQ3xwYxBSv2962SKRUPVDHEldM485bKpJDtvDc8UsMBn2+9Ro5Rn8oML +aBC2bPQvvVSMUaUHYQ082LvPO1hJep1EQfntFV0r9q23uxXKtzZc6JoyK7+lhEi69eQtV 83ptNLjh+csdjZ0eXcCcLb9n0s7aQhE= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-549-PXal9Dt7NMuRjAP3HZJqCQ-1; Tue, 25 Apr 2023 23:18:42 -0400 X-MC-Unique: PXal9Dt7NMuRjAP3HZJqCQ-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-4edd5a7cddeso7924607e87.0 for ; Tue, 25 Apr 2023 20:18:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682479121; x=1685071121; 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=KtkS8QZe/o00VB0DHK7QzgrrGugl8akH2mYVPDK5a8k=; b=OtrbaHeaLeyTwepkD5Iw1ac8hv4f4b33vZLfVqd6SNSSKJvJgUoFVeIlWhzsBv4FNy jC0dll+1ZwckOyvw3hucYFOh1ZWei40W7v41SuEn2TIHflxzACubeoxUzBGyuDLFsRcT X4zvS3ewGGkDWmvPFbbWCp9zz++NsBLTzErzVASIOfXZKN2VCMygp/5HBodjwkpYoXkA 9h2uAMwPVbOP0s1ri8lAwjTHx6FJikXUrQFxKOLTpebKE+8UvQS/g4lVJDAOaRytrOeN cDz490yYvv6i97EF7xOnwTArKxCmcqC0iIkBv/DJ4JEbknPVf8yn9k5Y+s95tHLayM2C xUgg== X-Gm-Message-State: AC+VfDzMcf5gHhRpZcpwo9dMh5Vkj4xTcmUUB2m5EnVL0A7ybmR3a4LB xel/4DPYxAjF7z+sKW4abGxhDhWsSftmHJzkaEnjbU0NkmB3TyCfd+NrxEOxIamuqb0RzGA+AMQ e0AGEVkF7YA== X-Received: by 2002:a05:6512:11ec:b0:4ef:ed90:1f3a with SMTP id p12-20020a05651211ec00b004efed901f3amr210409lfs.0.1682479120969; Tue, 25 Apr 2023 20:18:40 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6Dw3RqruaPelklsbGwUGKPyyyX+X2gawZomjV+ANDWFBwBLmycH3J29SHyb3v8a+8L3O6asg== X-Received: by 2002:a05:6512:11ec:b0:4ef:ed90:1f3a with SMTP id p12-20020a05651211ec00b004efed901f3amr210375lfs.0.1682479120575; Tue, 25 Apr 2023 20:18:40 -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 p13-20020a19f00d000000b004efd57c198dsm1779335lfc.53.2023.04.25.20.18.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Apr 2023 20:18:39 -0700 (PDT) Message-ID: Date: Wed, 26 Apr 2023 06:18:38 +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 v4] 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: <3b92d56f55671a0389252379237703df6e86ea48.1682464032.git.lstoakes@gmail.com> From: =?UTF-8?Q?Mika_Penttil=c3=a4?= In-Reply-To: <3b92d56f55671a0389252379237703df6e86ea48.1682464032.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: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 640D480006 X-Rspamd-Server: rspam01 X-Stat-Signature: mzbtsnasmwh9rxg63c77jn4q7768a54n X-HE-Tag: 1682479124-734580 X-HE-Meta: U2FsdGVkX18jFBZ3B+Kb4zp7Lvtl2p5fJxFrwWxBwZSUgHV+7cpJM/o9qAWH1v/805zroFzcmk3SGkNz6gQTaVz9stNG3zJZEQJINGkFfmvorIKhCFkonlOKQ8OPOiInQc4bZnv5Fl/IXu3i5UF+PWA8HY3o3wMtF5to3QKRf10C6bRVnpA/p4kNMvtshcGY5m77u1AtEqNxhrguCSXfidcLAHl8D8qW/H53eTSF1aIR/KZSz7LoEI6YIYFPgpbP9V9YR6UT4rNIQssHNOyUhLR3yWQ+E8SaY8nXEpbcdrrwASBgTmrE5UL8nfxFNiwiYCQxq9pHRZ7v5lEc9Dafpky98c84K5iuruNuSLwPo2I8bI2Ed0USQfshokOiHZOY5tZexXDRVjILBiCr4m8rDfwXnY55EZnKX6/1GtbGyTeNK8efU7I/3kpryWIZUj1t1flrCUGwVgO/TDn7WgAb6nQAlF0r6uft6p/B+gfx7ZoPDU3ysKjysE6DD6uCdaTLzRgEuYsRnaw+Em1qbPgUyiD/FjRHBozlLFk65HjDsGOiscHaWcoTlP4Ys9FnYpyu4Bmt8MEHnC9VgPzlpw9OGm6EyuJKIpQvSGPihUqaccP4cSkOv7gJPjiuZ0JLFDs5ImoFpRS+VqwsmU07r4CqfXexl7LvYNg6nFgwENmLes/tRFU8y5sadbaauSy8Uw0wVl8q8mXklMdNlaFdYlefvJrJxzB/374EFoQhTXXkZTvcJQqotCXBsoLya8zHuXVBNoACop+2L55zk1LWnNtnJKmDwBP2M3H09RIbjVUUAsXz57QcjY+4oe+hkzuLAb26HnlwMKT0dFEpkJomTingUNP1bvkBVt7Hf2h90Px8dxRQMZO4TdzPePtiz4SKBZIliFSE10eJfof8Zmv3ZDIfkE6qleZ0g1vq1Wj/pQZqbwqpM5QC3AXQzPaO9lBPXSSJzr+dhwkcQQMUP9uO7tB 2cKl3b/B yWa+C+4zgv9VSIIg72kV/REkRN8iQRLQSgc+vAkh4aaHdhLa+Jq8gvk7z7OlSOqe07uaFA7LTTbuw0uvdF78MKD4HUorD3KwNvNJWonod9zqdILlhO15/Tb6M6iyWTmX8unM1Y5f/iEoE4iPi3d1Fz4qbNZlkfQt850b3Q7ebOp/nBxyExGwcyJtvloCxrvuhK68wyIID8H9cSqI0D1hAAuYCDNcaB7mpsydAebhsuSqFU1ZEq5yeQFj/1wgko5aG00MIu7Ntxwth1YTwn05qS/0JQFw04K94EF0nAF2ubgW4XOPZzKGvSHwDAX0yRI/Pa0zaziMDQPPdlaLgsOUCcWtQrJxCWFUcvWQyzrMo/X4aiO4aYnRK6B5BsY3d5/mhGPW1B/cpGB+1+tRXXc5oCT0IYtmTo1He9T3XRKj25DFq7+u/kfEeACf6fq5XdwDAMrPd73OqV/Nuzm8Cpk3vR9EDABbDWrnO7JvXvKTu0eWabqaf/LazW8P+Wrh2euCsD1YY0/kM6R2ZNezxY76oX/6SZF6LTTPJWFbgnUfy1ZAXut3Ar2UafWh+5mF9jqWWZiea 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: Hi, On 26.4.2023 2.15, Lorenzo Stoakes wrote: > GUP does not correctly implement write-notify semantics, nor does it > guarantee that the underlying pages are correctly dirtied, which could lead > to a kernel oops or data corruption when writing to file-backed mappings. > > 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. > > In the meantime, we add a check for the most broken GUP case - > FOLL_LONGTERM - which really under no circumstances can safely access > dirty-tracked file mappings. > > 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. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Lorenzo Stoakes > --- > v4: > - Split out vma_needs_dirty_tracking() from vma_wants_writenotify() to reduce > duplication and update to use this in the GUP check. Note that both separately > check vm_ops_needs_writenotify() as the latter needs to test this before the > vm_pgprot_modify() test, resulting in vma_wants_writenotify() checking this > twice, however it is such a small check this should not be egregious. > > v3: > - Rebased on latest mm-unstable as of 24th April 2023. > - Explicitly check whether file system requires folio dirtying. Note that > vma_wants_writenotify() could not be used directly as it is very much focused > on determining if the PTE r/w should be set (e.g. assuming private mapping > does not require it as already set, soft dirty considerations). > - Tested code against shmem and hugetlb mappings - confirmed that these are not > disallowed by the check. > - Eliminate FOLL_ALLOW_BROKEN_FILE_MAPPING flag and instead perform check only > for FOLL_LONGTERM pins. > - As a result, limit check to internal GUP code. > https://lore.kernel.org/all/23c19e27ef0745f6d3125976e047ee0da62569d4.1682406295.git.lstoakes@gmail.com/ > > v2: > - Add accidentally excluded ptrace_access_vm() use of > FOLL_ALLOW_BROKEN_FILE_MAPPING. > - Tweak commit message. > https://lore.kernel.org/all/c8ee7e02d3d4f50bb3e40855c53bda39eec85b7d.1682321768.git.lstoakes@gmail.com/ > > v1: > https://lore.kernel.org/all/f86dc089b460c80805e321747b0898fd1efe93d7.1682168199.git.lstoakes@gmail.com/ > > include/linux/mm.h | 1 + > mm/gup.c | 26 +++++++++++++++++++++++++- > mm/mmap.c | 37 ++++++++++++++++++++++++++++--------- > 3 files changed, 54 insertions(+), 10 deletions(-) > > 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..53652453037c 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -959,16 +959,37 @@ 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 > + * may not adhere to the semantics expected by a file system. > + */ > +static inline bool can_write_file_mapping(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 +999,9 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > return -EFAULT; > > if (write) { > + if (!vma_anon && !can_write_file_mapping(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..aac638dd22cf 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1475,6 +1475,32 @@ 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 inline 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); > +} > + What would be the exact reproducer of the problem? AFAIK writenotify is handled (by handle_mm_fault()) for non cow mappings (shared), where it only matters. GUP will only allow FOLL_FORCE without faulting for PageAnonExclusive pages. So if you want something beyond normal cow semantics you have custom vm_ops (and mmap() and fault()) Also for longterm pinning gups vs fork vs swap there has been fixes by david recently. > /* > * Some shared mappings will want the pages marked read-only > * to track write events. If so, we'll downgrade vm_page_prot > @@ -1484,14 +1510,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 +1536,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); > } > > /* --Mika