Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1465045pxj; Fri, 21 May 2021 15:15:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/4LvHjzsIy3kwwPpxrvJ5xwkZmg+WjqnVizg0VsT24EoewHkyQLgGjPRvrxnz7ySoG4yX X-Received: by 2002:aa7:d413:: with SMTP id z19mr13386721edq.37.1621635345995; Fri, 21 May 2021 15:15:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621635345; cv=none; d=google.com; s=arc-20160816; b=Tt5n5Yn/5wqLkjz4co7HHIxpRP0jiKwe1UhMShaJgu7nXhr9wZBImsUWjfWC75wsCW xhx+vkkqk5UFvlTI42B0cLZNFWHqFGbExxPU7cErb6iQHqvu8PUPfVDTn1TbgoZucfeM pQrk7EchOYBp6BqBYvkENi2oJFwsAAG+IwYLGrC+8p5kw6P/r/HW0XhFfu0cDb6PTyxn g5f76acwRt4SQtUtpRkiAEuYEDHS5ava41AtkRH4Ie2nV+OWl0Amk8vyxudwi0vIWLbH I/t74jEsrFakEBBWziKbnWZitbTEHaN0v/V2l+R4VGqiGKvPUqXJQWVsofvoiWhP8Al2 6T9w== 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=GGngNRuRMTJAw6ddCVsYR6PDJPEika5023AInr9ZOVU=; b=ZB8M0us+jsPbDcija2A8Qt88PPgHfQvPii0/nh/NM/211BPI2+AeAwz97/6vwqG6ev hgBpDZKjOVqVgBOZwE/ohiPpcMULhv8e7nn27LNqxlzN97W8Q+lqAFazU/xqQ5Y3sIEg npBIsA7pV61x4bmVjWR0u0vFU0al1HzIjOk8f5BQKUX8ofDHfwbYhv+yFpkIYboKB/Rx v2F7ofJlC48M6i05hXrlM2ItLhj/am7VFg7Q3UWMO19FZyFkmT3LLCuKW2/c6WN1/WSW u1f9rZ9X9bZT8RvS+whRo+rueZSRGUKAS3gOiWeZqdJXQtvyoKz9Otf5p3C6z2/t2fFs 2Mog== 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 bd21si5942525edb.261.2021.05.21.15.15.21; Fri, 21 May 2021 15:15:45 -0700 (PDT) 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 S230106AbhEUWP3 (ORCPT + 99 others); Fri, 21 May 2021 18:15:29 -0400 Received: from mga09.intel.com ([134.134.136.24]:55677 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230094AbhEUWOm (ORCPT ); Fri, 21 May 2021 18:14:42 -0400 IronPort-SDR: 0mqObyhoNPTOzLz4Th+trVoYrGjj6W5wUvXK64VwViSsjX/lo08XMnnH5pyoI6M8vv//g7nvb6 fSfIyA/e8QBA== X-IronPort-AV: E=McAfee;i="6200,9189,9991"; a="201618771" X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="201618771" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2021 15:13:17 -0700 IronPort-SDR: 8bd7lh9NKYiTQjZUTitrmmHd/zI0AGAKB4v3xJs25TIipTb079bG84mHw4hdLZ549k4dbLjP5W ny2bCZYrteXA== X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="441116205" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2021 15:13:17 -0700 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 , Haitao Huang Cc: Yu-cheng Yu , "Kirill A . Shutemov" Subject: [PATCH v27 20/31] mm: Update can_follow_write_pte() for shadow stack Date: Fri, 21 May 2021 15:12:00 -0700 Message-Id: <20210521221211.29077-21-yu-cheng.yu@intel.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20210521221211.29077-1-yu-cheng.yu@intel.com> References: <20210521221211.29077-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(). While at it, also split the long line into smaller ones. Signed-off-by: Yu-cheng Yu Reviewed-by: Kirill A. Shutemov Cc: Kees Cook --- v26: - Instead of passing vm_flags, pass down vma pointer to can_follow_write_*(). v25: - Split long line into smaller ones. v24: - Change arch_shadow_stack_mapping() to is_shadow_stack_mapping(). mm/gup.c | 16 ++++++++++++---- mm/huge_memory.c | 16 ++++++++++++---- 2 files changed, 24 insertions(+), 8 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index 0697134b6a12..432ba7ccf8ae 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -438,10 +438,18 @@ 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)); + if (pte_write(pte)) + return true; + if ((flags & (FOLL_FORCE | FOLL_COW)) != (FOLL_FORCE | FOLL_COW)) + return false; + if (!pte_dirty(pte)) + return false; + if (is_shadow_stack_mapping(vma->vm_flags)) + return false; + return true; } static struct page *follow_page_pte(struct vm_area_struct *vma, @@ -484,7 +492,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 819f6c32eb5b..99352caf7188 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1337,10 +1337,18 @@ 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)); + if (pmd_write(pmd)) + return true; + if ((flags & (FOLL_FORCE | FOLL_COW)) != (FOLL_FORCE | FOLL_COW)) + return false; + if (!pmd_dirty(pmd)) + return false; + if (is_shadow_stack_mapping(vma->vm_flags)) + return false; + return true; } struct page *follow_trans_huge_pmd(struct vm_area_struct *vma, @@ -1353,7 +1361,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