Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp607975pxb; Wed, 27 Jan 2021 16:36:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJyBbrc3/XWGHKPjr5xVJzeMGHteKmM1ekRdZrqjIgyfuCMgcFr3d74BtK38qhwQTStwYz9X X-Received: by 2002:a05:6402:100b:: with SMTP id c11mr11201394edu.193.1611794170730; Wed, 27 Jan 2021 16:36:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611794170; cv=none; d=google.com; s=arc-20160816; b=UU8MFG7Bg+ZvjSRESAQlYM9qEKaU6WIZv3nql6fXyySNFcFbPeFJ0Z9KF9u+bxPhyh 6Vufsltn7VB6qMZ849bsUDx8xbIjyGwl5P6oc4TClY+Z/5w12R7DA7eoZP98jaNaRYmO Kz6WKw3dxEuhF6cGXYoDF44VzBg1rGZVIhPMZfwbSQdXiHBb0kc+pZPPBq5FP1IoHJzH yiWmoKio9QblPK9xcj07Jxlp7hRlyLxykg1IaA+49ILLRxty2oCSZRoyLLdhcGUYA7u2 AGi/poD4iuIcYQnZOCQHf0N/rDE/j12eSQatSYj8Mz8u51EYMQ66VJHNICr5+4mL+Q/D ZdsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=5H8hjxlkdvPb45bcVkkKV4tSUYptTJIYikrbUINq/tA=; b=FaXlQHLGwC+pYqfC5uDBSOZ36S8XExGHv3RjwDlGEGeurZtLeQ3n3EBZOA3Q3uCnC1 iH4t1DHU702aNS3Rrbl8Emf/5eIvq4GR8rvTLTmQdWLWUTjrSoq1Fm9phdwjfPuwjIlU lMNnO36oYqBzcJkJfifJhGz2H6DGIFPD+hrkSKKROvFkHrcmJCcRzunKWAX/KpKv4QVY MhY76AnG3HBCWkxKkU1Ys+yb5xAnd0iDxiEfkUo+AMGPpXenW0EIKJsHgisnhekAdCWl UudBg1U4TGbalX/LW6JbZ1BPKlZ6s9e75Nyf0RRkKhJQVAafaMv2x4SSxmsMP+XkCJXF b+8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u10si1516105ejr.222.2021.01.27.16.35.46; Wed, 27 Jan 2021 16:36:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232688AbhA0VfE (ORCPT + 99 others); Wed, 27 Jan 2021 16:35:04 -0500 Received: from mga04.intel.com ([192.55.52.120]:48882 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235290AbhA0VcH (ORCPT ); Wed, 27 Jan 2021 16:32:07 -0500 IronPort-SDR: aOmwZcyX6wz+A9y1XbWJOVTzOMKFfCPUGUKYLSG1Gxfh8yvVOqOUyGdsFBAp6fbS/CPmapQYzV Dzq/QMW8oS2g== X-IronPort-AV: E=McAfee;i="6000,8403,9877"; a="177573163" X-IronPort-AV: E=Sophos;i="5.79,380,1602572400"; d="scan'208";a="177573163" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 13:25:59 -0800 IronPort-SDR: /R+g7993UgUxuqbFRIhvCPCoXW0c9uNTxaQC5nSb4Tzl4I4EqTgxWFnx1sEa7RpmYIPoiM31s7 WgjBA+LkyHLw== X-IronPort-AV: E=Sophos;i="5.79,380,1602572400"; d="scan'208";a="353948247" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 13:25:58 -0800 From: Yu-cheng Yu To: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu Cc: Yu-cheng Yu Subject: [PATCH v18 18/25] mm: Update can_follow_write_pte() for shadow stack Date: Wed, 27 Jan 2021 13:25:17 -0800 Message-Id: <20210127212524.10188-19-yu-cheng.yu@intel.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20210127212524.10188-1-yu-cheng.yu@intel.com> References: <20210127212524.10188-1-yu-cheng.yu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Can_follow_write_pte() ensures a read-only page is COWed by checking the FOLL_COW flag, and uses pte_dirty() to validate the flag is still valid. Like a writable data page, a shadow stack page is writable, and becomes read-only during copy-on-write, but it is always dirty. Thus, in the can_follow_write_pte() check, it belongs to the writable page case and should be excluded from the read-only page pte_dirty() check. Apply the same changes to can_follow_write_pmd(). Signed-off-by: Yu-cheng Yu --- mm/gup.c | 8 +++++--- mm/huge_memory.c | 8 +++++--- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index e4c224cd9661..66ab67626f57 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -357,10 +357,12 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address, * FOLL_FORCE can write to even unwritable pte's, but only * after we've gone through a COW cycle and they are dirty. */ -static inline bool can_follow_write_pte(pte_t pte, unsigned int flags) +static inline bool can_follow_write_pte(pte_t pte, unsigned int flags, + struct vm_area_struct *vma) { return pte_write(pte) || - ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte)); + ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte) && + !arch_shadow_stack_mapping(vma->vm_flags)); } static struct page *follow_page_pte(struct vm_area_struct *vma, @@ -403,7 +405,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, } if ((flags & FOLL_NUMA) && pte_protnone(pte)) goto no_page; - if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) { + if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags, vma)) { pte_unmap_unlock(ptep, ptl); return NULL; } diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bfec65c9308b..eb64e2b56bc9 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1337,10 +1337,12 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd) * FOLL_FORCE can write to even unwritable pmd's, but only * after we've gone through a COW cycle and they are dirty. */ -static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags) +static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags, + struct vm_area_struct *vma) { return pmd_write(pmd) || - ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd)); + ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd) && + !arch_shadow_stack_mapping(vma->vm_flags)); } struct page *follow_trans_huge_pmd(struct vm_area_struct *vma, @@ -1353,7 +1355,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma, assert_spin_locked(pmd_lockptr(mm, pmd)); - if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags)) + if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags, vma)) goto out; /* Avoid dumping huge zero page */ -- 2.21.0