Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp5074928rwr; Sun, 23 Apr 2023 20:47:53 -0700 (PDT) X-Google-Smtp-Source: AKy350abJlXK7dg7Lm2QETuFhe13QIAbhpl4kKdyPTbIRb/z0JNMpOOFYoboV06fZ6z1LQW4aMC5 X-Received: by 2002:a05:6a20:258f:b0:f5:8681:14c3 with SMTP id k15-20020a056a20258f00b000f5868114c3mr1192021pzd.46.1682308073283; Sun, 23 Apr 2023 20:47:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682308073; cv=none; d=google.com; s=arc-20160816; b=TZWloJE43FB7tEbE4FVP8qNLJUGwKLBayN1ootXkUqwqG4YohBYydB+oBI2irxvvW2 /zZHJyICxzgXhutgFak27Du3aQyFhpHs7VVdNKF6vIEPicLmJ1AvwOAbQGRS3SygqWZT E/XxZGmKOm4bv0KFOUr5FYZIuPAGj3MBCbcqsyySXi9Un5Toc8TjLaq/6rcD5xJcAgKo q3C282CcvX3goxvXPSlekLOz1hSG0w0RZUQVDmlIM3HWlqjV+phDY4bGgl//1zzUYddn m/zxfeVvgtGpwEqnH+vkfhT/4sN9SSxctw0/iQJBekyet4gWfB7P+nenbfW+pLyUvekw gYMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=x0/Gqmlp5F3e84VZzqWw27RJ/qxOUG7Vcqc9AjwjGKg=; b=WjxE5XNS6BVYpZUAUQl2PYenhf6YDyZ0RrEGnAbwDavFIBQmQxxCFn7Gl2Vo5RIe9y zx6NjZyaNeuk4L5Fhkal+nUqTGcI+gAAckTyzgU2zuUJ2bzOn+hiYImBkDuDa7X4I6n9 k5+vIyO0MW/ehr5whVKrhsmqcRFTse5stqseyxqPgdd0B23KikHXEjezTPc54E7jYaiD 1NtoDscxYzPS7zDMNdd96IhYbykW+nqx80p1kuoaFTqHNOg3bo+662zW4rXYZ4LLYIAx CqjzV4aY8QRXSpxljnKj6qDKTwWTD79qv0NUseL+vZtCgo/nDJxjX2W4C6WuAfL7oS4N ev7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AzTGiB1Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a28-20020aa78e9c000000b00626007418c3si10072297pfr.289.2023.04.23.20.47.41; Sun, 23 Apr 2023 20:47:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AzTGiB1Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229548AbjDXDoN (ORCPT + 99 others); Sun, 23 Apr 2023 23:44:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbjDXDoB (ORCPT ); Sun, 23 Apr 2023 23:44:01 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C76454226 for ; Sun, 23 Apr 2023 20:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682307707; 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=x0/Gqmlp5F3e84VZzqWw27RJ/qxOUG7Vcqc9AjwjGKg=; b=AzTGiB1ZrW+SwucpM3JDSeSyylyq2cDV/Qu82ms9Sit6G284sL998VXFeqeEtOSZNHqRu5 TiB25mThqncpt1JWrXBMCE77qQNU3zJErn+UB5eA2qJyWhvfJLALmeNtSnOKWYtKGnlIJg 2gk7IEY/H1Cam63VYU9xClEW+Wi7p3M= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-164-y5gjHoYXObGbDSnILzX-nQ-1; Sun, 23 Apr 2023 23:41:46 -0400 X-MC-Unique: y5gjHoYXObGbDSnILzX-nQ-1 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-4ecb06abc1aso1715363e87.3 for ; Sun, 23 Apr 2023 20:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682307701; x=1684899701; 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=x0/Gqmlp5F3e84VZzqWw27RJ/qxOUG7Vcqc9AjwjGKg=; b=iwjxvmdYmYp/lV3EhkOs+bg47F9U5kG9fgU3RRbuWhZILGbW0P4lz9Z67P8UzgmnKl 6MFPTOUK9q2LvwlGSRH8GvoSL7trYexfjpERClh24odFPBisRK/AdVPGMUT2ZBcDLiq4 0+Lv7ZylnsgLPbO8g6IRfxgJA9hKj0/lIb6Oj1JV9ksu6Syhuv1Yl67vCfXMLeiLfGT2 S1DVe8eZdqE2AhM7dk9GJo6dldWfy2wRaZEILIg9Ctl0ZRG5seg3JvwZ94dN6zHyaCpf ZhZXkmFcPGRB2WHTaAIuUKuSQFhylGjLlUeNzKWIgHbR545pCKU0BGFXh7c3xIT9lwWL vywA== X-Gm-Message-State: AAQBX9dt9Piw2P0ifFLNRmnf1etGYmzCydO2+GGdhoGbUn4K9bpfuY0s Y8t6+j1wjd8qvS57onHrqCLTd7vN5xgQWc5GatWcT+/UxBmRPs/faH9HYF29xnN/H+Ryi446d8D BTEepTPi37toSClaGuvkk+A0= X-Received: by 2002:a19:c503:0:b0:4db:513b:6ef4 with SMTP id w3-20020a19c503000000b004db513b6ef4mr2801670lfe.11.1682307701253; Sun, 23 Apr 2023 20:41:41 -0700 (PDT) X-Received: by 2002:a19:c503:0:b0:4db:513b:6ef4 with SMTP id w3-20020a19c503000000b004db513b6ef4mr2801666lfe.11.1682307700896; Sun, 23 Apr 2023 20:41: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 a5-20020a056512374500b004db3d57c3a8sm1510791lfs.96.2023.04.23.20.41.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Apr 2023 20:41:40 -0700 (PDT) Message-ID: <4b599782-3512-a177-c5b5-c562a22886c7@redhat.com> Date: Mon, 24 Apr 2023 06:41: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] mm/gup: disallow GUP writing to file-backed mappings by default Content-Language: en-US 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 References: From: =?UTF-8?Q?Mika_Penttil=c3=a4?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 22.4.2023 16.37, Lorenzo Stoakes wrote: > It isn't safe to write to file-backed mappings as GUP does not ensure that > the semantics associated with such a write are performed correctly, for > instance filesystems which rely upon write-notify will not be correctly > notified. > > There are exceptions to this - shmem and hugetlb mappings are (in effect) > anonymous mappings by other names so we do permit this operation in these > cases. > > In addition, if no pinning takes place (neither FOLL_GET nor FOLL_PIN is > specified and neither flags gets implicitly set) then no writing can occur > so we do not perform the check in this instance. > > This is an important exception, as populate_vma_page_range() invokes > __get_user_pages() in this way (and thus so does __mm_populate(), used by > MAP_POPULATE mmap() and mlock() invocations). > > There are GUP users within the kernel that do nevertheless rely upon this > behaviour, so we introduce the FOLL_ALLOW_BROKEN_FILE_MAPPING flag to > explicitly permit this kind of GUP access. > > This is required in order to not break userspace in instances where the > uAPI might permit file-mapped addresses - a number of RDMA users require > this for instance, as do the process_vm_[read/write]v() system calls, > /proc/$pid/mem, ptrace and SDT uprobes. Each of these callers have been > updated to use this flag. > > Making this change is an important step towards a more reliable GUP, and > explicitly indicates which callers might encouter issues moving forward. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Lorenzo Stoakes > --- > drivers/infiniband/hw/qib/qib_user_pages.c | 3 +- > drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +- > drivers/infiniband/sw/siw/siw_mem.c | 3 +- > fs/proc/base.c | 3 +- > include/linux/mm_types.h | 8 +++++ > kernel/events/uprobes.c | 3 +- > mm/gup.c | 36 +++++++++++++++++++++- > mm/memory.c | 3 +- > mm/process_vm_access.c | 2 +- > net/xdp/xdp_umem.c | 2 +- > 10 files changed, 56 insertions(+), 9 deletions(-) > > diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c > index f693bc753b6b..b9019dad8008 100644 > --- a/drivers/infiniband/hw/qib/qib_user_pages.c > +++ b/drivers/infiniband/hw/qib/qib_user_pages.c > @@ -110,7 +110,8 @@ int qib_get_user_pages(unsigned long start_page, size_t num_pages, > for (got = 0; got < num_pages; got += ret) { > ret = pin_user_pages(start_page + got * PAGE_SIZE, > num_pages - got, > - FOLL_LONGTERM | FOLL_WRITE, > + FOLL_LONGTERM | FOLL_WRITE | > + FOLL_ALLOW_BROKEN_FILE_MAPPING, > p + got, NULL); > if (ret < 0) { > mmap_read_unlock(current->mm); > diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c > index 2a5cac2658ec..33cf79b248a9 100644 > --- a/drivers/infiniband/hw/usnic/usnic_uiom.c > +++ b/drivers/infiniband/hw/usnic/usnic_uiom.c > @@ -85,7 +85,7 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable, > int dmasync, struct usnic_uiom_reg *uiomr) > { > struct list_head *chunk_list = &uiomr->chunk_list; > - unsigned int gup_flags = FOLL_LONGTERM; > + unsigned int gup_flags = FOLL_LONGTERM | FOLL_ALLOW_BROKEN_FILE_MAPPING; > struct page **page_list; > struct scatterlist *sg; > struct usnic_uiom_chunk *chunk; > diff --git a/drivers/infiniband/sw/siw/siw_mem.c b/drivers/infiniband/sw/siw/siw_mem.c > index f51ab2ccf151..bc3e8c0898e5 100644 > --- a/drivers/infiniband/sw/siw/siw_mem.c > +++ b/drivers/infiniband/sw/siw/siw_mem.c > @@ -368,7 +368,8 @@ struct siw_umem *siw_umem_get(u64 start, u64 len, bool writable) > struct mm_struct *mm_s; > u64 first_page_va; > unsigned long mlock_limit; > - unsigned int foll_flags = FOLL_LONGTERM; > + unsigned int foll_flags = > + FOLL_LONGTERM | FOLL_ALLOW_BROKEN_FILE_MAPPING; > int num_pages, num_chunks, i, rv = 0; > > if (!can_do_mlock()) > diff --git a/fs/proc/base.c b/fs/proc/base.c > index 96a6a08c8235..3e3f5ea9849f 100644 > --- a/fs/proc/base.c > +++ b/fs/proc/base.c > @@ -855,7 +855,8 @@ static ssize_t mem_rw(struct file *file, char __user *buf, > if (!mmget_not_zero(mm)) > goto free; > > - flags = FOLL_FORCE | (write ? FOLL_WRITE : 0); > + flags = FOLL_FORCE | FOLL_ALLOW_BROKEN_FILE_MAPPING | > + (write ? FOLL_WRITE : 0); > > while (count > 0) { > size_t this_len = min_t(size_t, count, PAGE_SIZE); > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 3fc9e680f174..e76637b4c78f 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -1185,6 +1185,14 @@ enum { > FOLL_PCI_P2PDMA = 1 << 10, > /* allow interrupts from generic signals */ > FOLL_INTERRUPTIBLE = 1 << 11, > + /* > + * By default we disallow write access to known broken file-backed > + * memory mappings (i.e. anything other than hugetlb/shmem > + * mappings). Some code may rely upon being able to access this > + * regardless for legacy reasons, thus we provide a flag to indicate > + * this. > + */ > + FOLL_ALLOW_BROKEN_FILE_MAPPING = 1 << 12, > > /* See also internal only FOLL flags in mm/internal.h */ > }; > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index 59887c69d54c..ec330d3b0218 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -373,7 +373,8 @@ __update_ref_ctr(struct mm_struct *mm, unsigned long vaddr, short d) > return -EINVAL; > > ret = get_user_pages_remote(mm, vaddr, 1, > - FOLL_WRITE, &page, &vma, NULL); > + FOLL_WRITE | FOLL_ALLOW_BROKEN_FILE_MAPPING, > + &page, &vma, NULL); > if (unlikely(ret <= 0)) { > /* > * We are asking for 1 page. If get_user_pages_remote() fails, > diff --git a/mm/gup.c b/mm/gup.c > index 1f72a717232b..68d5570c0bae 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -959,16 +959,46 @@ static int faultin_page(struct vm_area_struct *vma, > return 0; > } > > +/* > + * Writing to file-backed mappings 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. > + * > + * In most instances we disallow this broken behaviour, however there are some > + * exceptions to this enforced here. > + */ > +static inline bool can_write_file_mapping(struct vm_area_struct *vma, > + unsigned long gup_flags) > +{ > + struct file *file = vma->vm_file; > + > + /* If we aren't pinning then no problematic write can occur. */ > + if (!(gup_flags & (FOLL_GET | FOLL_PIN))) > + return true; > + > + /* Special mappings should pose no problem. */ > + if (!file) > + return true; > + > + /* Has the caller explicitly indicated this case is acceptable? */ > + if (gup_flags & FOLL_ALLOW_BROKEN_FILE_MAPPING) > + return true; > + > + /* shmem and hugetlb mappings do not have problematic semantics. */ > + return vma_is_shmem(vma) || is_file_hugepages(file); > +} > + > 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 +1008,10 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > return -EFAULT; > > if (write) { > + if (!vma_anon && > + WARN_ON_ONCE(!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/memory.c b/mm/memory.c > index 146bb94764f8..e3d535991548 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -5683,7 +5683,8 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr, > if (!mm) > return 0; > > - ret = __access_remote_vm(mm, addr, buf, len, gup_flags); > + ret = __access_remote_vm(mm, addr, buf, len, > + gup_flags | FOLL_ALLOW_BROKEN_FILE_MAPPING); > > mmput(mm); > > diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c > index 78dfaf9e8990..ef126c08e89c 100644 > --- a/mm/process_vm_access.c > +++ b/mm/process_vm_access.c > @@ -81,7 +81,7 @@ static int process_vm_rw_single_vec(unsigned long addr, > ssize_t rc = 0; > unsigned long max_pages_per_loop = PVM_MAX_KMALLOC_PAGES > / sizeof(struct pages *); > - unsigned int flags = 0; > + unsigned int flags = FOLL_ALLOW_BROKEN_FILE_MAPPING; > > /* Work out address and page range required */ > if (len == 0) > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c > index 02207e852d79..b93cfcaccb0d 100644 > --- a/net/xdp/xdp_umem.c > +++ b/net/xdp/xdp_umem.c > @@ -93,7 +93,7 @@ void xdp_put_umem(struct xdp_umem *umem, bool defer_cleanup) > > static int xdp_umem_pin_pages(struct xdp_umem *umem, unsigned long address) > { > - unsigned int gup_flags = FOLL_WRITE; > + unsigned int gup_flags = FOLL_WRITE | FOLL_ALLOW_BROKEN_FILE_MAPPING; > long npgs; > int err; > Not sure about this in general, but seemss at least ptrace (ptrace_access_vm()) seems to be broken here.. --Mika