Message ID | 20221203003606.6838-9-rick.p.edgecombe@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1142001wrr; Fri, 2 Dec 2022 16:39:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf6Z4IKxX+AU6VzLzthGd+TBofyg/WVGDcpXHmblGdl9rHGSfmPEO6K5BEjyCQ64qY+6tLe8 X-Received: by 2002:aa7:d45a:0:b0:46b:9af6:5bf7 with SMTP id q26-20020aa7d45a000000b0046b9af65bf7mr14524487edr.391.1670027954040; Fri, 02 Dec 2022 16:39:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670027954; cv=none; d=google.com; s=arc-20160816; b=NMuJhVj6Hhmp3KCJwAXHltMPIPlAD85a5SrYG9a8mXNf9IyEhzAiaHqIU2lDMK1rYl 5+w99X9apsLGVeYJZMBewMQWrnRNa4W5zX5FUWu/bVpk/KCOVYoWp1/Y8cOAqQ3H23gR VsJ3x1rnagqKE52xuq7BLiWFnx+bGznr5EEaoEAXGYe9BYOoZUuSceqyiVE9rk4YkcvJ 4uje74HlwEMiT0v2jms6MFJQRoUXDCWtSgcEMZOoZbbjgOC0ZH5zlWQqMiXF6FNPka3g M3n2qzryq+VrB3Or3d/zkaHAvUHuxIdoCLd+C8pZVaxjDBQ5TJ9HRCEJr8hwDPOtKZzf YbwA== 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=z1lXjmab9iUB/QO7egQSmrhdMAK9Cqh+IBIczqpovLo=; b=rmlga8E9PtSiDmqWXuFZTAAUYPDdeqLA04Ojigaz085E7+sqOS7qOKDgBQ7NKGzrCT jO0m6YRLYXCEd2I2TsBsoBFI+tUntXbe1O63+KwwxrHyGOys+6ROxwg2Vx/rRpjHiouo PNjbTZ43Z31xi51J1+ctuO5FWK46ugich3zpVHs9uLcFF8MZaEbGbM3ej8BhKbMscQpH bGBqhhtI8+JGOWjSOMsNmiUrbfCh414eyo3gA2wZgCo+zOhWTbMMHDf1GQyjFJenEo0+ kjk8Y1UYkD47M18S7Fq5o6c9ySpb5TDmtKwD/m0L4Cf5XipuyZ2bfIgo1YWv3jYhUdp9 8/Eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="OMb+/FNS"; 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 br13-20020a170906d14d00b007c0bd0edd7esi2844194ejb.906.2022.12.02.16.38.50; Fri, 02 Dec 2022 16:39:14 -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="OMb+/FNS"; 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 S235120AbiLCAhz (ORCPT <rfc822;lhua1029@gmail.com> + 99 others); Fri, 2 Dec 2022 19:37:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235054AbiLCAhI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 2 Dec 2022 19:37:08 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDC2BF9320; Fri, 2 Dec 2022 16:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670027808; x=1701563808; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=TsPAiG3CKuUoTXIA4KxoLuEUjC7epYmiZKW9UfFSzwA=; b=OMb+/FNSfmLNY8sAT6idYapYkv02LG0MiWCUd1Pv4X0NzrRji6j8HZdT Nczw6fBMLwBFnKZF0AF148Y7V2v86xyEelRb1leooTO/KuQQV2K7Cs9lA ADpYKVYDxOzuV63nFAw1j2Z2DDjfo6SGKLw38ysDsL5yyf5mIVsUDwiyH fvlfBrLWYyDrmPrGO8M0XSpYgd4FVQfqsVyz6a0iTk85RJ2qogDgP5a6x ++tzQKpos9zdhI75D88NpsJVDS7evd2TJSn9qoFsnxbjyDOQXpIqWVXQX z2srebCANNz85bixJo43Stp8T8RpmS5rTjDH2802j42YzJliuW7HERmsC w==; X-IronPort-AV: E=McAfee;i="6500,9779,10549"; a="313710825" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="313710825" 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:36:47 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10549"; a="787479790" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="787479790" 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:36:43 -0800 From: Rick Edgecombe <rick.p.edgecombe@intel.com> To: x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 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 <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>, Balbir Singh <bsingharora@gmail.com>, Borislav Petkov <bp@alien8.de>, Cyrill Gorcunov <gorcunov@gmail.com>, Dave Hansen <dave.hansen@linux.intel.com>, Eugene Syromiatnikov <esyr@redhat.com>, Florian Weimer <fweimer@redhat.com>, "H . J . Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Mike Kravetz <mike.kravetz@oracle.com>, Nadav Amit <nadav.amit@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>, Peter Zijlstra <peterz@infradead.org>, Randy Dunlap <rdunlap@infradead.org>, Weijiang Yang <weijiang.yang@intel.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, John Allen <john.allen@amd.com>, 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, Yu-cheng Yu <yu-cheng.yu@intel.com>, Christoph Hellwig <hch@lst.de> Subject: [PATCH v4 08/39] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Date: Fri, 2 Dec 2022 16:35:35 -0800 Message-Id: <20221203003606.6838-9-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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751151231548448060?= X-GMAIL-MSGID: =?utf-8?q?1751151231548448060?= |
Series |
Shadow stacks for userspace
|
|
Commit Message
Edgecombe, Rick P
Dec. 3, 2022, 12:35 a.m. UTC
From: Yu-cheng Yu <yu-cheng.yu@intel.com> New processors that support Shadow Stack regard Write=0,Dirty=1 PTEs as shadow stack pages. In normal cases, it can be helpful to create Write=1 PTEs as also Dirty=1 if HW dirty tracking is not needed, because if the Dirty bit is not already set the CPU has to set Dirty=1 when it the memory gets written to. This creates addiontal work for the CPU. So tradional wisdom was to simply set the Dirty bit whenever you didn't care about it. However, it was never really very helpful for read only kernel memory. When CR4.CET=1 and IA32_S_CET.SH_STK_EN=1, some instructions can write to such supervisor memory. The kernel does not set IA32_S_CET.SH_STK_EN, so avoiding kernel Write=0,Dirty=1 memory is not strictly needed for any functional reason. But having Write=0,Dirty=1 kernel memory doesn't have any functional benefit either, so to reduce ambiguity between shadow stack and regular Write=0 pages, removed Dirty=1 from any kernel Write=0 PTEs. Tested-by: Pengfei Xu <pengfei.xu@intel.com> Tested-by: John Allen <john.allen@amd.com> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> --- v3: - Update commit log (Andrew Cooper, Peterz) v2: - Normalize PTE bit descriptions between patches arch/x86/include/asm/pgtable_types.h | 6 +++--- arch/x86/mm/pat/set_memory.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
Comments
On Fri, Dec 02, 2022 at 04:35:35PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > New processors that support Shadow Stack regard Write=0,Dirty=1 PTEs as > shadow stack pages. > > In normal cases, it can be helpful to create Write=1 PTEs as also Dirty=1 > if HW dirty tracking is not needed, because if the Dirty bit is not already > set the CPU has to set Dirty=1 when it the memory gets written to. This > creates addiontal work for the CPU. So tradional wisdom was to simply set > the Dirty bit whenever you didn't care about it. However, it was never > really very helpful for read only kernel memory. > > When CR4.CET=1 and IA32_S_CET.SH_STK_EN=1, some instructions can write to > such supervisor memory. The kernel does not set IA32_S_CET.SH_STK_EN, so > avoiding kernel Write=0,Dirty=1 memory is not strictly needed for any > functional reason. But having Write=0,Dirty=1 kernel memory doesn't have > any functional benefit either, so to reduce ambiguity between shadow stack > and regular Write=0 pages, removed Dirty=1 from any kernel Write=0 PTEs. > > Tested-by: Pengfei Xu <pengfei.xu@intel.com> > Tested-by: John Allen <john.allen@amd.com> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org>
Just typos and spelling fixes: On Fri, Dec 02, 2022 at 04:35:35PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > New processors that support Shadow Stack regard Write=0,Dirty=1 PTEs as > shadow stack pages. > > In normal cases, it can be helpful to create Write=1 PTEs as also Dirty=1 > if HW dirty tracking is not needed, because if the Dirty bit is not already > set the CPU has to set Dirty=1 when it the memory gets written to. This s/it // > creates addiontal work for the CPU. "additional" > So tradional wisdom was to simply set Unknown word [tradional] in commit message. Suggestions: ['traditional', ... > the Dirty bit whenever you didn't care about it. However, it was never > really very helpful for read only kernel memory. read-only > When CR4.CET=1 and IA32_S_CET.SH_STK_EN=1, some instructions can write to > such supervisor memory. The kernel does not set IA32_S_CET.SH_STK_EN, so > avoiding kernel Write=0,Dirty=1 memory is not strictly needed for any > functional reason. But having Write=0,Dirty=1 kernel memory doesn't have > any functional benefit either, so to reduce ambiguity between shadow stack > and regular Write=0 pages, removed Dirty=1 from any kernel Write=0 PTEs. s/removed/remove/
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index 447d4bee25c4..0646ad00178b 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -192,10 +192,10 @@ enum page_cache_mode { #define _KERNPG_TABLE (__PP|__RW| 0|___A| 0|___D| 0| 0| _ENC) #define _PAGE_TABLE_NOENC (__PP|__RW|_USR|___A| 0|___D| 0| 0) #define _PAGE_TABLE (__PP|__RW|_USR|___A| 0|___D| 0| 0| _ENC) -#define __PAGE_KERNEL_RO (__PP| 0| 0|___A|__NX|___D| 0|___G) -#define __PAGE_KERNEL_ROX (__PP| 0| 0|___A| 0|___D| 0|___G) +#define __PAGE_KERNEL_RO (__PP| 0| 0|___A|__NX| 0| 0|___G) +#define __PAGE_KERNEL_ROX (__PP| 0| 0|___A| 0| 0| 0|___G) #define __PAGE_KERNEL_NOCACHE (__PP|__RW| 0|___A|__NX|___D| 0|___G| __NC) -#define __PAGE_KERNEL_VVAR (__PP| 0|_USR|___A|__NX|___D| 0|___G) +#define __PAGE_KERNEL_VVAR (__PP| 0|_USR|___A|__NX| 0| 0|___G) #define __PAGE_KERNEL_LARGE (__PP|__RW| 0|___A|__NX|___D|_PSE|___G) #define __PAGE_KERNEL_LARGE_EXEC (__PP|__RW| 0|___A| 0|___D|_PSE|___G) #define __PAGE_KERNEL_WP (__PP|__RW| 0|___A|__NX|___D| 0|___G| __WP) diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c index 0db69514fe29..50e07e8493e0 100644 --- a/arch/x86/mm/pat/set_memory.c +++ b/arch/x86/mm/pat/set_memory.c @@ -2055,7 +2055,7 @@ int set_memory_nx(unsigned long addr, int numpages) int set_memory_ro(unsigned long addr, int numpages) { - return change_page_attr_clear(&addr, numpages, __pgprot(_PAGE_RW), 0); + return change_page_attr_clear(&addr, numpages, __pgprot(_PAGE_RW | _PAGE_DIRTY), 0); } int set_memory_rox(unsigned long addr, int numpages)