Message ID | 20230613001108.3040476-15-rick.p.edgecombe@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp222217vqr; Mon, 12 Jun 2023 17:44:40 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5msHY6lGijmFxF3MfHkUF1ARe6bbWnS06Sz9geo4Y4vX8U/jP4okvHfacFcTN3EYMufnnn X-Received: by 2002:a17:907:6d1e:b0:977:b397:bbfa with SMTP id sa30-20020a1709076d1e00b00977b397bbfamr11604699ejc.6.1686617079475; Mon, 12 Jun 2023 17:44:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686617079; cv=none; d=google.com; s=arc-20160816; b=MIzustIurYAoECorxhmGI8tAt0GOtf3mIS3KDSfMEyzEZoQJbT9IK8vZ2mkltaHRNM mA9yIVD+kFUuNFCxgpuTVNSsvIpjeQLVFkKatAFApyRo1GvotoPPMmO+gQlkDtPHNkwu H0GkbF0cjSBKPMOpdN4cootrUfPlSKlvvMzdfT19R7ECAtRlPv4Zr/Um2N7tpInl8MHc b+MgODNQKmpWsW6Vr4oouqirTA3UktXhZodPoE6PyhWLaJ9C+XTCvUmyp/GvLWQ5zL7l 0T5wnSchL4tX22VsE/dETfVKCabN6TdE+1CK0fR8YvJ45vHyX8wcqhGojSyEPujm+RJ7 jFEQ== 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 :dkim-signature; bh=FOFVMBXtKB8/Hcfbd8g/yK53EZfWd2ezBu+ZFVQ6/dM=; b=wNd0ZwJ2uXWovUuIJ4n9MQdARa18JvgagrRbH0rPYIP6APAiupykj0x0Xr0zK2MxKf PeSJuLWdopnJxRCNec6J1sXDyij2Qh4FoMXpwZePtNsb+guFq8nTRBKrXqAd4xNkq+1r 87o14HLE629L+1H31fMlxQIDjy+UkLXLBp1U2LQXAw2wDasu4kSTwAwFYo5Xgr+4XjpN /bGrjr6mr5WzkQkvRR2boHSeIN3B2RkPEp423l742QQt25V6oQBucGnK/bDyZq9o0vIv DrZx+lG+9KCTkiwxvipbYpU/+odzb21MWzn+aHpTBsqHPCQugwrmhh2lZnc0rkaf+Xr1 2TFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=n8if8qdQ; 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 ko6-20020a170907986600b0097461d96871si6471228ejc.968.2023.06.12.17.44.15; Mon, 12 Jun 2023 17:44:39 -0700 (PDT) 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=n8if8qdQ; 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 S239003AbjFMANU (ORCPT <rfc822;rust.linux@gmail.com> + 99 others); Mon, 12 Jun 2023 20:13:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238845AbjFMAMe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Jun 2023 20:12:34 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1FC51730; Mon, 12 Jun 2023 17:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686615146; x=1718151146; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=svMWn5R9eThoiar+k0qdORAiS7Vwyk8B+BTeN3eLytc=; b=n8if8qdQukN6W8TFmTvv6muKDj4494uFDuN6u1F5bMSfjuF5qAXnnQTP ucPwzsXPUCkf/zNUJ/SubFkseQj/EOOSA1UaozanhV5uAp/yJukoXs6ha mnAjNh4Fw0yRlMxyzgKtEw0vmz3/QQxLIRsAUrelYmH+XNIH9W+gx6Ja6 BUbd26SHCizexRqcNBjfg/vpzbfjZ/NeuIuKlUV3bGLj8GYEiCCOGdH3L uJfwABlj6Fj9E6OX7umvycvJ+eD0Qp86f5lYriCkbUrqmekNIZjAO1yFT zM5j3yvLZ40VVMPqFe6poR5uhFC/MHWQadrCOEnwjns+FcE21gQQ4GdoU Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="361556974" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="361556974" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 17:12:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="835671022" X-IronPort-AV: E=Sophos;i="6.00,238,1681196400"; d="scan'208";a="835671022" Received: from almeisch-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.amr.corp.intel.com) ([10.209.42.242]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 17:12:19 -0700 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, david@redhat.com, debug@rivosinc.com, szabolcs.nagy@arm.com, torvalds@linux-foundation.org, broonie@kernel.org Cc: rick.p.edgecombe@intel.com, Yu-cheng Yu <yu-cheng.yu@intel.com>, Pengfei Xu <pengfei.xu@intel.com> Subject: [PATCH v9 14/42] mm: Introduce VM_SHADOW_STACK for shadow stack memory Date: Mon, 12 Jun 2023 17:10:40 -0700 Message-Id: <20230613001108.3040476-15-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> References: <20230613001108.3040476-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1768546190552984239?= X-GMAIL-MSGID: =?utf-8?q?1768546190552984239?= |
Series |
Shadow stacks for userspace
|
|
Commit Message
Edgecombe, Rick P
June 13, 2023, 12:10 a.m. UTC
From: Yu-cheng Yu <yu-cheng.yu@intel.com> New hardware extensions implement support for shadow stack memory, such as x86 Control-flow Enforcement Technology (CET). Add a new VM flag to identify these areas, for example, to be used to properly indicate shadow stack PTEs to the hardware. Shadow stack VMA creation will be tightly controlled and limited to anonymous memory to make the implementation simpler and since that is all that is required. The solution will rely on pte_mkwrite() to create the shadow stack PTEs, so it will not be required for vm_get_page_prot() to learn how to create shadow stack memory. For this reason document that VM_SHADOW_STACK should not be mixed with VM_SHARED. 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> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Tested-by: John Allen <john.allen@amd.com> Tested-by: Kees Cook <keescook@chromium.org> --- Documentation/filesystems/proc.rst | 1 + fs/proc/task_mmu.c | 3 +++ include/linux/mm.h | 8 ++++++++ 3 files changed, 12 insertions(+)
Comments
On 13.06.23 02:10, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > New hardware extensions implement support for shadow stack memory, such > as x86 Control-flow Enforcement Technology (CET). Add a new VM flag to > identify these areas, for example, to be used to properly indicate shadow > stack PTEs to the hardware. > > Shadow stack VMA creation will be tightly controlled and limited to > anonymous memory to make the implementation simpler and since that is all > that is required. The solution will rely on pte_mkwrite() to create the > shadow stack PTEs, so it will not be required for vm_get_page_prot() to > learn how to create shadow stack memory. For this reason document that > VM_SHADOW_STACK should not be mixed with VM_SHARED. > > 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> > Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> > Reviewed-by: Kees Cook <keescook@chromium.org> > Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> > Tested-by: Pengfei Xu <pengfei.xu@intel.com> > Tested-by: John Allen <john.allen@amd.com> > Tested-by: Kees Cook <keescook@chromium.org> > --- > Documentation/filesystems/proc.rst | 1 + > fs/proc/task_mmu.c | 3 +++ > include/linux/mm.h | 8 ++++++++ > 3 files changed, 12 insertions(+) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index 7897a7dafcbc..6ccb57089a06 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -566,6 +566,7 @@ encoded manner. The codes are the following: > mt arm64 MTE allocation tags are enabled > um userfaultfd missing tracking > uw userfaultfd wr-protect tracking > + ss shadow stack page > == ======================================= > > Note that there is no guarantee that every flag and associated mnemonic will > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 420510f6a545..38b19a757281 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -711,6 +711,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) > #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR > [ilog2(VM_UFFD_MINOR)] = "ui", > #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ > +#ifdef CONFIG_X86_USER_SHADOW_STACK > + [ilog2(VM_SHADOW_STACK)] = "ss", > +#endif > }; > size_t i; > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 6f52c1e7c640..fb17cbd531ac 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -319,11 +319,13 @@ extern unsigned int kobjsize(const void *objp); > #define VM_HIGH_ARCH_BIT_2 34 /* bit only usable on 64-bit architectures */ > #define VM_HIGH_ARCH_BIT_3 35 /* bit only usable on 64-bit architectures */ > #define VM_HIGH_ARCH_BIT_4 36 /* bit only usable on 64-bit architectures */ > +#define VM_HIGH_ARCH_BIT_5 37 /* bit only usable on 64-bit architectures */ > #define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0) > #define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1) > #define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2) > #define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3) > #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4) > +#define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5) > #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */ > > #ifdef CONFIG_ARCH_HAS_PKEYS > @@ -339,6 +341,12 @@ extern unsigned int kobjsize(const void *objp); > #endif > #endif /* CONFIG_ARCH_HAS_PKEYS */ > > +#ifdef CONFIG_X86_USER_SHADOW_STACK > +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 /* Should not be set with VM_SHARED */ > +#else > +# define VM_SHADOW_STACK VM_NONE > +#endif > + > #if defined(CONFIG_X86) > # define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */ > #elif defined(CONFIG_PPC) Acked-by: David Hildenbrand <david@redhat.com>
On Mon, Jun 12, 2023 at 05:10:40PM -0700, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@intel.com> > > New hardware extensions implement support for shadow stack memory, such > as x86 Control-flow Enforcement Technology (CET). Add a new VM flag to > identify these areas, for example, to be used to properly indicate shadow > stack PTEs to the hardware. Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org>
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 7897a7dafcbc..6ccb57089a06 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -566,6 +566,7 @@ encoded manner. The codes are the following: mt arm64 MTE allocation tags are enabled um userfaultfd missing tracking uw userfaultfd wr-protect tracking + ss shadow stack page == ======================================= Note that there is no guarantee that every flag and associated mnemonic will diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 420510f6a545..38b19a757281 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -711,6 +711,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR [ilog2(VM_UFFD_MINOR)] = "ui", #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ +#ifdef CONFIG_X86_USER_SHADOW_STACK + [ilog2(VM_SHADOW_STACK)] = "ss", +#endif }; size_t i; diff --git a/include/linux/mm.h b/include/linux/mm.h index 6f52c1e7c640..fb17cbd531ac 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -319,11 +319,13 @@ extern unsigned int kobjsize(const void *objp); #define VM_HIGH_ARCH_BIT_2 34 /* bit only usable on 64-bit architectures */ #define VM_HIGH_ARCH_BIT_3 35 /* bit only usable on 64-bit architectures */ #define VM_HIGH_ARCH_BIT_4 36 /* bit only usable on 64-bit architectures */ +#define VM_HIGH_ARCH_BIT_5 37 /* bit only usable on 64-bit architectures */ #define VM_HIGH_ARCH_0 BIT(VM_HIGH_ARCH_BIT_0) #define VM_HIGH_ARCH_1 BIT(VM_HIGH_ARCH_BIT_1) #define VM_HIGH_ARCH_2 BIT(VM_HIGH_ARCH_BIT_2) #define VM_HIGH_ARCH_3 BIT(VM_HIGH_ARCH_BIT_3) #define VM_HIGH_ARCH_4 BIT(VM_HIGH_ARCH_BIT_4) +#define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5) #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */ #ifdef CONFIG_ARCH_HAS_PKEYS @@ -339,6 +341,12 @@ extern unsigned int kobjsize(const void *objp); #endif #endif /* CONFIG_ARCH_HAS_PKEYS */ +#ifdef CONFIG_X86_USER_SHADOW_STACK +# define VM_SHADOW_STACK VM_HIGH_ARCH_5 /* Should not be set with VM_SHARED */ +#else +# define VM_SHADOW_STACK VM_NONE +#endif + #if defined(CONFIG_X86) # define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */ #elif defined(CONFIG_PPC)