From patchwork Sat Dec 3 00:35:50 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 29183 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1142906wrr; Fri, 2 Dec 2022 16:42:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf7CuAhnT4Oqt4+PMWCzD3uJ4qYJYb7z0USZnWFcnmhNQqTlsojNX8nLH4ILdrw7O+RckKld X-Received: by 2002:a17:906:fa89:b0:7c0:bc68:c00a with SMTP id lt9-20020a170906fa8900b007c0bc68c00amr6091917ejb.665.1670028153787; Fri, 02 Dec 2022 16:42:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670028153; cv=none; d=google.com; s=arc-20160816; b=ZFcODKB10Mp01OTWrlXN8DfhlFI3/8EZO0dAwm8c9rRldL0Q4EoM4YbcB/ZLzoUwke e0+yh5I1yp0dP4h7hYSkqxyCWgzKQZb1wTVO48q/rcGSkKdKB5T4/oRfNG9mBTeTdCyC EELLjz+thW9NmbCNXO+bMZRkYZEq+pKGIwgPjSEFQ2wPx7kNHXRyJ7iBFwM3+zj4WyFG tZ1ILg75uNUnLqkYnpV8uPOFt6xVePLc0zCScKgQ5I60hi1vKMIWZbwkXXciYsI2LZY6 vRUrYMbjwfIk/t/7K9w+EzawOvxs2OuNSdU2rav+/ELh9mWJ05EXd/m3u+RZv2ITq7zH C9cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=6nlk4qSz27C95X29zZwqpj4jHA+dpOluz8EuClfv5ZM=; b=EVLz5F8d+kyzLJncl4gY/tGstqtpyFvIzmeBJRhvXM10zYT3/MhvZruV8cXUjUzXir HSNsWDVwJXpP5u2SYnQN3kNCFCgjALZd/8S9po1zHmTqecos3dMB4ECjwHb3C72mQ7Cn EQ6AJcI906iOGGB1XMLft8Ik7jpHH2dc8ejaQ4qEd5ueXVlKJGOvXLB4/K14n12i0/0/ 2uAmSlrpjzd6ca7QkpwDB+L64UPIlRKf8bvfdEif66cXrEIsN41qqo+NRdDWyiqxJ37b UyG9zc0bPdn/fUi387qYocE4YfDN0KlEvUhPuLfIQRA4f2m+5RSAkJNezMMST8lQ8DqA FW/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bqCzhTrL; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ww1-20020a170907084100b007826de24087si5717809ejb.228.2022.12.02.16.42.10; Fri, 02 Dec 2022 16:42:33 -0800 (PST) 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=@intel.com header.s=Intel header.b=bqCzhTrL; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235061AbiLCAla (ORCPT + 99 others); Fri, 2 Dec 2022 19:41:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235167AbiLCAkV (ORCPT ); Fri, 2 Dec 2022 19:40:21 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82E2F2714D; Fri, 2 Dec 2022 16:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670027885; x=1701563885; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=1B1fGdYaOUBrZLGly7/XqlrrigTtV2P34Ygy1ZAid0o=; b=bqCzhTrLzuACW+fDTw40WUtiRqWIcKe1jxjbK2fzdHu7aOzyqvBoUIVD UQkMU92E/N3xaky63L4zT+k4pPbqL0MJ1DPIjY5OePhnHac6iYRtbvyzr BEai8dkhWPyfaZye8eb5Q7Uj9ccEooMESzVyhPiSB6uuyKlXNihoWoATS ifBmVqRTCyCX+FqhPNbhaP344/K1SR3vDcd5AhkOkb2rIhpy0T1/1HW6w EeHroZ1BaYZrMyUm/lm+GuYyTRKKK+2TRKrlxmBCqYJMg095tp3wkp4WQ 5OTcYjelcBnTuObEzpAjHaqNGXNHOI3swaZ9NRqiAfaKp0WTkfb8j07y1 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10549"; a="313711220" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="313711220" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 16:37:23 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10549"; a="787479934" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="787479934" Received: from bgordon1-mobl1.amr.corp.intel.com (HELO rpedgeco-desk.amr.corp.intel.com) ([10.212.211.211]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 16:37:22 -0800 From: Rick Edgecombe 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 , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com Cc: rick.p.edgecombe@intel.com Subject: [PATCH v4 23/39] mm: Don't allow write GUPs to shadow stack memory Date: Fri, 2 Dec 2022 16:35:50 -0800 Message-Id: <20221203003606.6838-24-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221203003606.6838-1-rick.p.edgecombe@intel.com> References: <20221203003606.6838-1-rick.p.edgecombe@intel.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751151441105739152?= X-GMAIL-MSGID: =?utf-8?q?1751151441105739152?= The x86 Control-flow Enforcement Technology (CET) feature includes a new type of memory called shadow stack. This shadow stack memory has some unusual properties, which requires some core mm changes to function properly. Shadow stack memory is writable only in very specific, controlled ways. However, since it is writable, the kernel treats it as such. As a result there remain many ways for userspace to trigger the kernel to write to shadow stack's via get_user_pages(, FOLL_WRITE) operations. To make this a little less exposed, block writable GUPs for shadow stack VMAs. Still allow FOLL_FORCE to write through shadow stack protections, as it does for read-only protections. Tested-by: Pengfei Xu Tested-by: John Allen Signed-off-by: Rick Edgecombe Reviewed-by: Kees Cook --- v3: - Add comment in __pte_access_permitted() (Dave) - Remove unneeded shadow stack specific check in __pte_access_permitted() (Jann) arch/x86/include/asm/pgtable.h | 5 +++++ mm/gup.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index a89dfa9174ae..945d58681a87 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1636,6 +1636,11 @@ static inline bool __pte_access_permitted(unsigned long pteval, bool write) { unsigned long need_pte_bits = _PAGE_PRESENT|_PAGE_USER; + /* + * Write=0,Dirty=1 PTEs are shadow stack, which the kernel + * shouldn't generally allow access to, but since they + * are already Write=0, the below logic covers both cases. + */ if (write) need_pte_bits |= _PAGE_RW; diff --git a/mm/gup.c b/mm/gup.c index cdff87343884..75e8d3853ff3 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1062,7 +1062,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) return -EFAULT; if (write) { - if (!(vm_flags & VM_WRITE)) { + if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) { if (!(gup_flags & FOLL_FORCE)) return -EFAULT; /*