From patchwork Mon May 3 23:43:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 12237239 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFDBEC43462 for ; Mon, 3 May 2021 23:44:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83D9F61183 for ; Mon, 3 May 2021 23:44:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83D9F61183 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 273026B006E; Mon, 3 May 2021 19:44:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CA88D0002; Mon, 3 May 2021 19:44:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0771B6B0071; Mon, 3 May 2021 19:44:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id D6D7E6B006E for ; Mon, 3 May 2021 19:44:04 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7BD43181AEF39 for ; Mon, 3 May 2021 23:44:04 +0000 (UTC) X-FDA: 78101550408.14.BC93627 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 98B6090009ED for ; Mon, 3 May 2021 23:43:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620085443; 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=SgqZKuzF10VtS2gxChk76nX04SENhfjxF8qh9wfVxX4=; b=ORcIQxCuyRHRIFJtHQh27vJDbLJxXOJsno1UHrfCz6MV8y2WkzCl0Ehtn/5Gz+3lcTHTIp FBROu43thx6p4B7HHkJNCDiSuTUOz29Sy6ZmO0hp/jsas0sYr+ZbPkD2VXg4IBxjE2RmVZ zwOQgkIEOoXjFvkvkdLL4LDyYFLmvAQ= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-tdcAg0FqOJGkpuG1-kmkXw-1; Mon, 03 May 2021 19:44:02 -0400 X-MC-Unique: tdcAg0FqOJGkpuG1-kmkXw-1 Received: by mail-qt1-f200.google.com with SMTP id j3-20020ac874c30000b02901bab5879d6aso2484266qtr.0 for ; Mon, 03 May 2021 16:44:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SgqZKuzF10VtS2gxChk76nX04SENhfjxF8qh9wfVxX4=; b=Ibl05yB2YbzOM3STOI4uOlIWbxC/dv8ReY+ryLx+l+WzatsMtVPUSUp3r33TwXjEbx fD5cvwAvo/BPAKitsfbDrTBxeC5o2tEjS4bpD16P2RYpyxKVgRwBwF6iP2uWr60P3AJI fXqZI/wTbMkj7+0i3Tw53xcs7KMU3lT9Qj+Uff6T/614a0ESzdR4B9cglQeuTVBau4C8 pgqbeTdf5qefD74vDZ3jMlMipBTd4LO4q6iqHKALfHVUUkygf/sKCOQvwTkuyFwG0Kbo 43+aQz6BcVnU0lcTCxjbjNx3idz8y4oi+qZr7S8doncT+IQbYavquQHObo9BDtm17wSh 7+Iw== X-Gm-Message-State: AOAM531+ocoFLNxsrlJvxO9KBaXD6t2Pe8DSEFs/LbtRWrFqr5NQQURF 3kYlAoDo/7tc0TBc64ujGr7wRbAm/ukYF8dGa0i88TTxhcMTnBYIJyeUk8CP/IpfV8VSBllsDh9 wRYaxXxL/8W4OyMZ9flcEVNw7bxgpahbQp4tMs5sjhiHZw4dfF7gdyxlZgivo X-Received: by 2002:ac8:7f04:: with SMTP id f4mr20100496qtk.88.1620085441331; Mon, 03 May 2021 16:44:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3/uFtTC37fwDHvfixViADg9ZV7qQj5qPTP5MX0Fsx6PvguTQXzqTCXbAffm0dw2XKzN9yPQ== X-Received: by 2002:ac8:7f04:: with SMTP id f4mr20100473qtk.88.1620085441017; Mon, 03 May 2021 16:44:01 -0700 (PDT) Received: from t490s.redhat.com (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id 189sm7126903qkh.99.2021.05.03.16.43.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 May 2021 16:44:00 -0700 (PDT) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Axel Rasmussen , Andrea Arcangeli , Andrew Morton , peterx@redhat.com, Mike Kravetz , Hugh Dickins , Joel Fernandes , stable@vger.kernel.org Subject: [PATCH v2 1/2] mm/hugetlb: Fix F_SEAL_FUTURE_WRITE Date: Mon, 3 May 2021 19:43:55 -0400 Message-Id: <20210503234356.9097-2-peterx@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210503234356.9097-1-peterx@redhat.com> References: <20210503234356.9097-1-peterx@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 98B6090009ED X-Stat-Signature: fprc8cipnog3tdwd3txib8cmmfs5m5um Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ORcIQxCu; spf=none (imf19.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620085412-687935 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: F_SEAL_FUTURE_WRITE is missing for hugetlb starting from the first day. There is a test program for that and it fails constantly. $ ./memfd_test hugetlbfs memfd-hugetlb: CREATE memfd-hugetlb: BASIC memfd-hugetlb: SEAL-WRITE memfd-hugetlb: SEAL-FUTURE-WRITE mmap() didn't fail as expected Aborted (core dumped) I think it's probably because no one is really running the hugetlbfs test. Fix it by checking FUTURE_WRITE also in hugetlbfs_file_mmap() as what we do in shmem_mmap(). Generalize a helper for that. Cc: Joel Fernandes (Google) Cc: stable@vger.kernel.org Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Reported-by: Hugh Dickins Reviewed-by: Mike Kravetz Signed-off-by: Peter Xu --- fs/hugetlbfs/inode.c | 5 +++++ include/linux/mm.h | 32 ++++++++++++++++++++++++++++++++ mm/shmem.c | 22 ++++------------------ 3 files changed, 41 insertions(+), 18 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 9b383c39756a5..6557cf2cb1879 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -131,6 +131,7 @@ static void huge_pagevec_release(struct pagevec *pvec) static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) { struct inode *inode = file_inode(file); + struct hugetlbfs_inode_info *info = HUGETLBFS_I(inode); loff_t len, vma_len; int ret; struct hstate *h = hstate_file(file); @@ -146,6 +147,10 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) vma->vm_flags |= VM_HUGETLB | VM_DONTEXPAND; vma->vm_ops = &hugetlb_vm_ops; + ret = seal_check_future_write(info->seals, vma); + if (ret) + return ret; + /* * page based offset in vm_pgoff could be sufficiently large to * overflow a loff_t when converted to byte offset. This can diff --git a/include/linux/mm.h b/include/linux/mm.h index d6790ab0cf575..b9b2caf9302bc 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3238,5 +3238,37 @@ extern int sysctl_nr_trim_pages; void mem_dump_obj(void *object); +/** + * seal_check_future_write - Check for F_SEAL_FUTURE_WRITE flag and handle it + * @seals: the seals to check + * @vma: the vma to operate on + * + * Check whether F_SEAL_FUTURE_WRITE is set; if so, do proper check/handling on + * the vma flags. Return 0 if check pass, or <0 for errors. + */ +static inline int seal_check_future_write(int seals, struct vm_area_struct *vma) +{ + if (seals & F_SEAL_FUTURE_WRITE) { + /* + * New PROT_WRITE and MAP_SHARED mmaps are not allowed when + * "future write" seal active. + */ + if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) + return -EPERM; + + /* + * Since an F_SEAL_FUTURE_WRITE sealed memfd can be mapped as + * MAP_SHARED and read-only, take care to not allow mprotect to + * revert protections on such mappings. Do this only for shared + * mappings. For private mappings, don't need to mask + * VM_MAYWRITE as we still want them to be COW-writable. + */ + if (vma->vm_flags & VM_SHARED) + vma->vm_flags &= ~(VM_MAYWRITE); + } + + return 0; +} + #endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ diff --git a/mm/shmem.c b/mm/shmem.c index a1f21736ad68e..250b52e682590 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2258,25 +2258,11 @@ int shmem_lock(struct file *file, int lock, struct user_struct *user) static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct shmem_inode_info *info = SHMEM_I(file_inode(file)); + int ret; - if (info->seals & F_SEAL_FUTURE_WRITE) { - /* - * New PROT_WRITE and MAP_SHARED mmaps are not allowed when - * "future write" seal active. - */ - if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) - return -EPERM; - - /* - * Since an F_SEAL_FUTURE_WRITE sealed memfd can be mapped as - * MAP_SHARED and read-only, take care to not allow mprotect to - * revert protections on such mappings. Do this only for shared - * mappings. For private mappings, don't need to mask - * VM_MAYWRITE as we still want them to be COW-writable. - */ - if (vma->vm_flags & VM_SHARED) - vma->vm_flags &= ~(VM_MAYWRITE); - } + ret = seal_check_future_write(info->seals, vma); + if (ret) + return ret; /* arm64 - allow memory tagging on RAM-based files */ vma->vm_flags |= VM_MTE_ALLOWED; From patchwork Mon May 3 23:43:56 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 12237237 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6848CC433B4 for ; Mon, 3 May 2021 23:44:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0CC79611EE for ; Mon, 3 May 2021 23:44:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CC79611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8B6DD8D0003; Mon, 3 May 2021 19:44:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F40B8D0002; Mon, 3 May 2021 19:44:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67AF58D0003; Mon, 3 May 2021 19:44:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 4E68A8D0002 for ; Mon, 3 May 2021 19:44:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 06E65249A for ; Mon, 3 May 2021 23:44:06 +0000 (UTC) X-FDA: 78101550492.23.11BE8BA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id D29F1C0007C4 for ; Mon, 3 May 2021 23:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620085445; 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=ABt25pzgCO1gaqcFMnixhdZW8Kc2SCW/u3hnQ6DkL1o=; b=dc7Iax5/KJqm2pKl9Eehhk8i27A/XiVsb3STeefTgM/DZsHaj+4jW05NMvmRDNwfNcWWwK ltjDq1NqE3Es5LSZNEnD3qtQyYYNy7YHDGYfPZVsfewX0mdBhc1GgIlAnF65xlEbJqF5sP jwWRnxBolt4McHS+RpxNtVN3ns8kZYk= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-27-C_WMgh7TNqy8ewHVgLOgyQ-1; Mon, 03 May 2021 19:44:03 -0400 X-MC-Unique: C_WMgh7TNqy8ewHVgLOgyQ-1 Received: by mail-qt1-f199.google.com with SMTP id a15-20020a05622a02cfb02901b5e54ac2e5so2486248qtx.4 for ; Mon, 03 May 2021 16:44:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ABt25pzgCO1gaqcFMnixhdZW8Kc2SCW/u3hnQ6DkL1o=; b=jJFVafw7RuBSg/OprlSgiqS3uIq0Y7KzBl6ZTYxDaS5CtwCepg4bUCSsi4pONlaHiI VokQyyDyO+dUo7cBbGwaMM5l0CFDyZamVM+GDv/qZqysm5Pz0ibLO9yoDBc2Ek3zjqSF 8B4z7UHvgI3xx0kY1vRBOe82nGm1Oy/DFAV15GvuhEXNbtWHPuAu/tsBrIxY6e3UGRts BjTbIoK86y4/cjZJPJT4eZNqs8nSAXSoFaQB2NiOLPzpi6YMzz39gdup6mhR0cM1akB8 SMyROYCD0TVzjMxysCSQT5FKzcwaGS7YryQG36ViZ74oX9NOPd1fgwHLNFdXg3zfHI9G UcqA== X-Gm-Message-State: AOAM533lG8FgiLT51BCPgGZXvEYAGw0dvVULP4M8TYp6oQ6lnGLgH5Gb 9TwbT5ZKb+jVmoZGJnPORAER8EVv1hvMa6zj1G7dINyhPieyiSaX8N95xpmRT4zu/K5I2qBy51I uQNsm0Ou1y+fYNLZhS8ZvxeMXv5ExVmOJ4zy6D3X+SmxI6KB/aRyhK7mFRe/7 X-Received: by 2002:a05:620a:799:: with SMTP id 25mr12553408qka.188.1620085442815; Mon, 03 May 2021 16:44:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvHpI4ndR9mV1KvzNSVtc1wN86uhUFbQX4EF4jyJbcv4dd7JFS0AMYcw+HYYlme5jwSVS1Rg== X-Received: by 2002:a05:620a:799:: with SMTP id 25mr12553383qka.188.1620085442514; Mon, 03 May 2021 16:44:02 -0700 (PDT) Received: from t490s.redhat.com (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id 189sm7126903qkh.99.2021.05.03.16.44.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 May 2021 16:44:01 -0700 (PDT) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Axel Rasmussen , Andrea Arcangeli , Andrew Morton , peterx@redhat.com, Mike Kravetz , Hugh Dickins , stable@vger.kernel.org Subject: [PATCH v2 2/2] mm/hugetlb: Fix cow where page writtable in child Date: Mon, 3 May 2021 19:43:56 -0400 Message-Id: <20210503234356.9097-3-peterx@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210503234356.9097-1-peterx@redhat.com> References: <20210503234356.9097-1-peterx@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D29F1C0007C4 X-Stat-Signature: obx7whuhzdts4fkf1h1zsmubb3r7pn9c Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="dc7Iax5/"; spf=none (imf03.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620085438-17392 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: When rework early cow of pinned hugetlb pages, we moved huge_ptep_get() upper but overlooked a side effect that the huge_ptep_get() will fetch the pte after wr-protection. After moving it upwards, we need explicit wr-protect of child pte or we will keep the write bit set in the child process, which could cause data corrution where the child can write to the original page directly. This issue can also be exposed by "memfd_test hugetlbfs" kselftest. Cc: stable@vger.kernel.org Fixes: 4eae4efa2c299 ("hugetlb: do early cow when page pinned on src mm") Reviewed-by: Mike Kravetz Signed-off-by: Peter Xu --- mm/hugetlb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index aab3a33214d10..72544ebb24f0e 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4076,6 +4076,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, * See Documentation/vm/mmu_notifier.rst */ huge_ptep_set_wrprotect(src, addr, src_pte); + entry = huge_pte_wrprotect(entry); } page_dup_rmap(ptepage, true);