From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA7F8C433EF for ; Sun, 6 Feb 2022 18:42:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B1456B0071; Sun, 6 Feb 2022 13:42:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 162466B0072; Sun, 6 Feb 2022 13:42:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 002946B0073; Sun, 6 Feb 2022 13:42:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id DD5686B0071 for ; Sun, 6 Feb 2022 13:42:27 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 82CAB8249980 for ; Sun, 6 Feb 2022 18:42:27 +0000 (UTC) X-FDA: 79113225534.04.976B381 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 02CFC140005 for ; Sun, 6 Feb 2022 18:42:26 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1C3B061158; Sun, 6 Feb 2022 18:42:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C1ADC340E9; Sun, 6 Feb 2022 18:42:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644172945; bh=ZHwFuWPqq+nhkelKsI7f7GhTLv5eAfwuxjFpnOSGkUw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XFEMDVTrzxclH7giQVni2jRu6plPDcf3UJ/7EUbvDlh69SL0zAiDc2t6xE/cfO8OJ 9IEE3sHgg2DFFwWK5n841pn1ZSr+yMXfKaP19Ldc2Rrkg+zzv38ieiUClHOFWwfYmv 00/mIVIJ59EJoGHgpcu1XPtsomQWUKJw24xggL7rKjWvvp152RczW5T4UDEcxeWDbk n+fd//WFpUVWKnzvRWQK440yQbyPORqxhohUou10VXJG3tWqbgVHZPmuChOXAR9mjT L/faPpS/HJQ/0d0cEQ+ohEY/zOHkGF3AoBIhzZ/XMI72TbHeXyGzrnOhKR61cTWSxz pv47Lht61R6dA== Date: Sun, 6 Feb 2022 20:42:03 +0200 From: Mike Rapoport To: Rick Edgecombe Cc: 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" , Dave Martin , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com, Andrei Vagin , Adrian Reber , Dmitry Safonov <0x7f454c46@gmail.com> Subject: Re: [PATCH 00/35] Shadow stacks for userspace Message-ID: References: <20220130211838.8382-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220130211838.8382-1-rick.p.edgecombe@intel.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 02CFC140005 X-Stat-Signature: 5rnyqy985htc5oz56sdxmgtj1yz1y4c9 X-Rspam-User: nil Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XFEMDVTr; spf=pass (imf26.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1644172946-809720 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: (added more CRIU people) On Sun, Jan 30, 2022 at 01:18:03PM -0800, Rick Edgecombe wrote: > Hi, >=20 > This is a slight reboot of the userspace CET series. I will be taking o= ver the=20 > series from Yu-cheng. Per some internal recommendations, I=E2=80=99ve r= eset the version > number and am calling it a new series. Hopefully, it doesn=E2=80=99t ca= use confusion. >=20 > The new plan is to upstream only userspace Shadow Stack support at this= point.=20 > IBT can follow later, but for now I=E2=80=99ll focus solely on the most= in-demand and > widely available (with the feature on AMD CPUs now) part of CET. >=20 > I thought as part of this reset, it might be useful to more fully write= -up the=20 > design and summarize the history of the previous CET series. So this sl= ightly > long cover letter does that. The "Updates" section has the changes, if = anyone > doesn't want the history. >=20 >=20 > Why is Shadow Stack Wanted > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > The main use case for userspace shadow stack is providing protection ag= ainst=20 > return oriented programming attacks. Fedora and Ubuntu already have man= y/most=20 > packages enabled for shadow stack. The main missing piece is Linux kern= el=20 > support and there seems to be a high amount of interest in the ecosyste= m for > getting this feature supported. Besides security, Google has also done = some > work on using shadow stack to improve performance and reliability of tr= acing. >=20 >=20 > Userspace Shadow Stack Implementation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Shadow stack works by maintaining a secondary (shadow) stack that canno= t be=20 > directly modified by applications. When executing a CALL instruction, t= he=20 > processor pushes the return address to both the normal stack and to the= special=20 > permissioned shadow stack. Upon ret, the processor pops the shadow stac= k copy=20 > and compares it to the normal stack copy. If the two differ, the proces= sor=20 > raises a control protection fault. This implementation supports shadow = stack on=20 > 64 bit kernels only, with support for 32 bit only via IA32 emulation. >=20 > Shadow Stack Memory > ------------------- > The majority of this series deals with changes for handling the specia= l=20 > shadow stack memory permissions. This memory is specified by the=20 > Dirty+RO PTE bits. A tricky aspect of this is that this combination wa= s=20 > previously used to specify COW memory. So Linux needs to handle COW=20 > differently when shadow stack is in use. The solution is to use a=20 > software PTE bit to denote COW memory, and take care to clear the dirt= y > bit when setting the memory RO. >=20 > Setup and Upkeep of HW Registers > -------------------------------- > Using userspace CET requires a CR4 bit set, and also the manipulation=20 > of two xsave managed MSRs. The kernel needs to modify these registers=20 > during various operations like clone and signal handling. These=20 > operations may happen when the registers are restored to the CPU, or=20 > saved in an xsave buffer. Since the recent AMX triggered FPU overhaul=20 > removed direct access to the xsave buffer, this series adds an=20 > interface to operate on the supervisor xstate. >=20 > New ABIs > -------- > This series introduces some new ABIs. The primary one is the shadow=20 > stack itself. Since it is readable and the shadow stack pointer is=20 > exposed to user space, applications can easily read and process the=20 > shadow stack. And in fact the tracing usages plan to do exactly that. >=20 > Most of the shadow stack contents are written by HW, but some of the=20 > entries are added by the kernel. The main place for this is signals. A= s=20 > part of handling the signal the kernel does some manual adjustment of=20 > the shadow stack that userspace depends on. >=20 > In addition to the contents of the shadow stack there is also user=20 > visible behavior around when new shadow stacks are created and set in=20 > the shadow stack pointer (SSP) register. This is relatively=20 > straightforward =E2=80=93 shadow stacks are created when new stacks ar= e created=20 > (thread creation, fork, etc). It is more or less what is required to=20 > keep apps working. >=20 > For situations when userspace creates a new stack (i.e. makecontext(),= =20 > fibers, etc), a new syscall is provided for creating shadow stack=20 > memory. To make the shadow stack usable, it needs to have a restore=20 > token written to the protected memory. So the syscall provides a way t= o=20 > specificity this should be done by the kernel. >=20 > When a shadow stack violation happens (when the return address of stac= k=20 > not matching return address in shadow stack), a segfault is generated=20 > with a new si_code specific to CET violations. >=20 > Lastly, a new arch_prctl interface is created for controlling the=20 > enablement of CET-like features. It is intended to also be used for=20 > LAM. It operates on the feature status per-thread, so for process wide= =20 > enabling it is intended to be used early in things like dynamic=20 > linker/loaders. However, it can be used later for per-thread enablemen= t=20 > of features like WRSS. >=20 > WRSS > ---- > WRSS is an instruction that can write to shadow stacks. The HW provide= s=20 > a way to enable this instruction for userspace use. Since shadow=20 > stack=E2=80=99s are created initially protected, enabling WRSS allows = any apps=20 > that want to do unusual things with their stacks to have a way to=20 > weaken protection and make things more flexible. A new feature bit is=20 > defined to control enabling/disabling of WRSS. >=20 >=20 > History > =3D=3D=3D=3D=3D=3D=3D > The branding =E2=80=9CCET=E2=80=9D really consists of two features: =E2= =80=9CShadow Stack=E2=80=9D and=20 > =E2=80=9CIndirect Branch Tracking=E2=80=9D. They both restrict previous= ly allowed, but rarely=20 > valid behaviors and require userspace to change to avoid these behavior= s before=20 > enabling the protection. These raw HW features need to be assembled int= o a=20 > software solution across userspace and kernel in order to add security = value. > The kernel part of this solution has evolved iteratively starting with = a lengthy > RFC period.=20 >=20 > Until now, the enabling effort was trying to support both Shadow Stack = and IBT.=20 > This history will focus on a few areas of the shadow stack development = history=20 > that I thought stood out. >=20 > Signals > ------- > Originally signals placed the location of the shadow stack restore=20 > token inside the saved state on the stack. This was problematic from a= =20 > past ABI promises perspective. So the restore location was instead jus= t=20 > assumed from the shadow stack pointer. This works because in normal=20 > allowed cases of calling sigreturn, the shadow stack pointer should be= =20 > right at the restore token at that time. There is no alternate shadow=20 > stack support. If an alt shadow stack is added later we would need to=20 > find a place to store the regular shadow stack token location. Options= =20 > could be to push something on the alt shadow stack, or to keep=20 > something on the kernel side. So the current design keeps things simpl= e=20 > while slightly kicking the can down the road if alt shadow stacks=20 > become a thing later. Siglongjmp is handled in glibc, using the incssp= =20 > instruction to unwind the shadow stack over the token. >=20 > Shadow Stack Allocation > ----------------------- > makecontext() implementations need a way to create new shadow stacks=20 > with restore token=E2=80=99s such that they can be pivoted to from use= rspace.=20 > The first interface to do this was an arch_prctl(). It created a shado= w=20 > stack with a restore token pre-setup, since the kernel has an=20 > instruction that can write to user shadow stacks. However, this=20 > interface was abandoned for being strange. >=20 > The next version created PROT_SHADOW_STACK. This interface had two=20 > problems. One, it left no options but for userspace to create writable= =20 > memory, write a restore token, then mproctect() it PROT_SHADOW_STACK.=20 > The writable window left the shadow stack exposed, weakening the=20 > security. Second, it caused problems with the guard pages. Since the=20 > memory was initially created writable it did not have a guard page, bu= t=20 > then was mprotected later to a type of memory that should have one.=20 > This resulted in missing guard pages and confused rb_subtree_gap=E2=80= =99s. >=20 > This version introduces a new syscall that behaves similarly to the=20 > initial arch_prctl() interface in that it has the kernel write the=20 > restore token. >=20 > Enabling Interface > ------------------ > For the entire history of the original CET series, the design was to=20 > enable shadow stack automatically if the feature bit was detected in=20 > the elf header. Then it was userspace=E2=80=99s responsibility to turn= it off=20 > via an arch_prctl() if it was not desired, and this was handled by the= =20 > glibc dynamic loader. Glibc=E2=80=99s standard behavior (when CET if c= onfigured=20 > is to leave shadow stack enabled if the executable and all linked=20 > libraries are marked with shadow stacks. >=20 > Many distros (Fedora and others) have binaries already marked with=20 > shadow stack, waiting for kernel support. Unfortunately their glibc=20 > binaries expect the original arch_prctl() interface for allocating=20 > shadow stacks, as those changes were pushed ahead of kernel support.=20 > The net result of it all is, when updating to a kernel with shadow=20 > stack these binaries would suddenly get shadow stack enabled and expec= t=20 > the arch_prctl() interface to be there. And so calls to makecontext()=20 > will fail, resulting in visible breakages. This series deals with this= =20 > problem as described below in "Updates". >=20 >=20 > Updates > =3D=3D=3D=3D=3D=3D=3D > These updates were mostly driven by public comments, but a lot of the d= esign=20 > elements are new. I would like some extra scrutiny on the updates. >=20 > New syscall for Shadow Stack Allocation > --------------------------------------- > A new syscall is added for allocating shadow stacks to replace=20 > PROT_SHADOW_STACK. Several options were considered, as described in th= e=20 > =E2=80=9Cx86/cet/shstk: Introduce map_shadow_stack syscall=E2=80=9D. >=20 > Xsave Managed Supervisor State Modifications > -------------------------------------------- > The shadow stack feature requires the kernel to modify xsaves managed=20 > state. On one of the last versions of Yu-cheng=E2=80=99s series Boris = had=20 > commented on the pattern it was using to do this not necessarily being= =20 > ideal. The pattern was to force a restore to the registers and always=20 > do the modification there. Then Thomas did an overhaul of the fpu code= ,=20 > part of which consisted of making raw access to the xsave buffer=20 > private to the fpu code. So this series tries to expose access again,=20 > and in a way that addresses Boris=E2=80=99 comments. >=20 > The method is to provide functions like wmsrl/rdmsrl, but that can=20 > direct the operation to the correct location (registers or buffer),=20 > while giving the proper notice to the fpu subsystem so things don=E2=80= =99t get=20 > clobbered or corrupted. >=20 > In the past a solution like this was discussed as part of the PASID=20 > series, and Thomas was not in favor. In CET=E2=80=99s case there is a = more=20 > logic around the CET MSR=E2=80=99s than in PASID's, and wrapping this = logic=20 > minimizes near identical open coded logic needed to do this more=20 > efficiently. In addition it resolves the above described problem of=20 > having no access to the xsave buffer. So it is being put forward here=20 > under the supposition that CET=E2=80=99s usage may lead to a different= =20 > conclusion, not to try to ignore past direction. >=20 > The user interrupt series has similar needs as CET, and will also use > this internal interface if it=E2=80=99s found acceptable. >=20 > Support for WRSS > ---------------- > Andy Lutomirski had asked if we change the shadow stack allocation API= =20 > such that userspace cannot create arbitrary shadow stacks, then we loo= k=20 > at exposing an interface to enable the WRSS instruction for userspace.= =20 > This way app=E2=80=99s that want to do unexpected things with shadow s= tacks=20 > would still have the option to create shadow stacks with arbitrary=20 > data. >=20 > Switch Enabling Interface > ------------------------- > As described above there is a problem with userspace binaries waiting=20 > to break as soon as the kernel supports CET. This needs to be prevente= d=20 > by changing the interface such that the old binaries will not enable=20 > shadow stack AND behave as if shadow stack is not enabled. They should= =20 > run normally without shadow stack protection. Creating a new feature=20 > (SHSTK2) for shadow stack was explored. SHSTK would never be supported= =20 > by the kernel, and all the userspace build tools would be updated to=20 > target SHSTK2 instead of SHSTK. So old SHSTK binaries would be cleanly > disabled. >=20 > But there are existing downsides to automatic elf header processing=20 > based enabling. The elf header feature spec is not defined by the=20 > kernel and there are proposals to expand it to describe additional=20 > logic. A simpler interface where the kernel is simply told what to=20 > enable, and leaves all the decision making to userspace, is more=20 > flexible for userspace and simpler for the kernel. There also already=20 > needs to be an ARCH_X86_FEATURE_ENABLE arch_prctl() for WRSS (and=20 > likely LAM will use it too), so it avoids there being two ways to turn= =20 > on these types of features. The only tricky part for shadow stack, is=20 > that it has to be enabled very early. Wherever the shadow stack is=20 > enabled, the app cannot return from that point, otherwise there will b= e=20 > a shadow stack violation. It turns out glibc can enable shadow stack=20 > this early, so it works nicely. So not automatically enabling any=20 > features in the elf header will cleanly disable all old binaries, whic= h=20 > expect the kernel to enable CET features automatically. Then after the= =20 > kernel changes are upstream, glibc can be updated to use the new > interface. This is the solution implemented in this series. >=20 > Expand Commit Logs > ------------------ > As part of spinning up on this series, I found some of the commit logs= =20 > did not describe the changes in enough detail for me understand their=20 > purpose. I tried to expand the logs and comments, where I had to go=20 > digging. Hopefully it=E2=80=99s useful. > =09 > Limit to only Intel Processors > ------------------------------ > Shadow stack is supported on some AMD processors, but this revision=20 > (with expanded HW usage and xsaves changes) has only has been tested o= n=20 > Intel ones. So this series has a patch to limit shadow stack support t= o=20 > Intel processors. Ideally the patch would not even make it to mainline= ,=20 > and should be dropped as soon as this testing is done. It's included=20 > just in case. >=20 >=20 > Future Work > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Even though this is now exclusively a shadow stack series, there is sti= ll some=20 > remaining shadow stack work to be done. >=20 > Ptrace > ------ > Early in the series, there was a patch to allow IA32_U_CET and > IA32_PL3_SSP to be set. This patch was dropped and planned as a follow > up to basic support, and it remains the plan. It will be needed for > in-progress gdb support. >=20 > CRIU Support > ------------ > In the past there was some speculation on the mailing list about=20 > whether CRIU would need to be taught about CET. It turns out, it does.= =20 > The first issue hit is that CRIU calls sigreturn directly from its=20 > =E2=80=9Cparasite code=E2=80=9D that it injects into the dumper proces= s. This violates > this shadow stack implementation=E2=80=99s protection that intends to = prevent > attackers from doing this. >=20 > With so many packages already enabled with shadow stack, there is=20 > probably desire to make it work seamlessly. But in the meantime if=20 > distros want to support shadow stack and CRIU, users could manually=20 > disabled shadow stack via =E2=80=9CGLIBC_TUNABLES=3Dglibc.cpu.x86_shst= k=3Doff=E2=80=9D for=20 > a process they will wants to dump. It=E2=80=99s not ideal. >=20 > I=E2=80=99d like to hear what people think about having shadow stack i= n the=20 > kernel without this resolved. Nothing would change for any users until= =20 > they enable shadow stack in the kernel and update to a glibc configure= d > with CET. Should CRIU userspace be solved before kernel support? >=20 > Selftests > --------- > There are some CET selftests being worked on and they are not included > here. >=20 > Thanks, >=20 > Rick >=20 > Rick Edgecombe (7): > x86/mm: Prevent VM_WRITE shadow stacks > x86/fpu: Add helpers for modifying supervisor xstate > x86/fpu: Add unsafe xsave buffer helpers > x86/cet/shstk: Introduce map_shadow_stack syscall > selftests/x86: Add map_shadow_stack syscall test > x86/cet/shstk: Support wrss for userspace > x86/cpufeatures: Limit shadow stack to Intel CPUs >=20 > Yu-cheng Yu (28): > Documentation/x86: Add CET description > x86/cet/shstk: Add Kconfig option for Shadow Stack > x86/cpufeatures: Add CET CPU feature flags for Control-flow > Enforcement Technology (CET) > x86/cpufeatures: Introduce CPU setup and option parsing for CET > x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states > x86/cet: Add control-protection fault handler > x86/mm: Remove _PAGE_DIRTY from kernel RO pages > x86/mm: Move pmd_write(), pud_write() up in the file > x86/mm: Introduce _PAGE_COW > drm/i915/gvt: Change _PAGE_DIRTY to _PAGE_DIRTY_BITS > x86/mm: Update pte_modify for _PAGE_COW > x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for > transition from _PAGE_DIRTY to _PAGE_COW > mm: Move VM_UFFD_MINOR_BIT from 37 to 38 > mm: Introduce VM_SHADOW_STACK for shadow stack memory > x86/mm: Check Shadow Stack page fault errors > x86/mm: Update maybe_mkwrite() for shadow stack > mm: Fixup places that call pte_mkwrite() directly > mm: Add guard pages around a shadow stack. > mm/mmap: Add shadow stack pages to memory accounting > mm: Update can_follow_write_pte() for shadow stack > mm/mprotect: Exclude shadow stack from preserve_write > mm: Re-introduce vm_flags to do_mmap() > x86/cet/shstk: Add user-mode shadow stack support > x86/process: Change copy_thread() argument 'arg' to 'stack_size' > x86/cet/shstk: Handle thread shadow stack > x86/cet/shstk: Introduce shadow stack token setup/verify routines > x86/cet/shstk: Handle signals for shadow stack > x86/cet/shstk: Add arch_prctl elf feature functions >=20 > .../admin-guide/kernel-parameters.txt | 4 + > Documentation/filesystems/proc.rst | 1 + > Documentation/x86/cet.rst | 145 ++++++ > Documentation/x86/index.rst | 1 + > arch/arm/kernel/signal.c | 2 +- > arch/arm64/kernel/signal.c | 2 +- > arch/arm64/kernel/signal32.c | 2 +- > arch/sparc/kernel/signal32.c | 2 +- > arch/sparc/kernel/signal_64.c | 2 +- > arch/x86/Kconfig | 22 + > arch/x86/Kconfig.assembler | 5 + > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/x86/ia32/ia32_signal.c | 25 +- > arch/x86/include/asm/cet.h | 54 +++ > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/include/asm/disabled-features.h | 8 +- > arch/x86/include/asm/fpu/api.h | 8 + > arch/x86/include/asm/fpu/types.h | 23 +- > arch/x86/include/asm/fpu/xstate.h | 6 +- > arch/x86/include/asm/idtentry.h | 4 + > arch/x86/include/asm/mman.h | 24 + > arch/x86/include/asm/mmu_context.h | 2 + > arch/x86/include/asm/msr-index.h | 20 + > arch/x86/include/asm/page_types.h | 7 + > arch/x86/include/asm/pgtable.h | 302 ++++++++++-- > arch/x86/include/asm/pgtable_types.h | 48 +- > arch/x86/include/asm/processor.h | 6 + > arch/x86/include/asm/special_insns.h | 30 ++ > arch/x86/include/asm/trap_pf.h | 2 + > arch/x86/include/uapi/asm/mman.h | 8 +- > arch/x86/include/uapi/asm/prctl.h | 10 + > arch/x86/include/uapi/asm/processor-flags.h | 2 + > arch/x86/kernel/Makefile | 1 + > arch/x86/kernel/cpu/common.c | 20 + > arch/x86/kernel/cpu/cpuid-deps.c | 1 + > arch/x86/kernel/elf_feature_prctl.c | 72 +++ > arch/x86/kernel/fpu/xstate.c | 167 ++++++- > arch/x86/kernel/idt.c | 4 + > arch/x86/kernel/process.c | 17 +- > arch/x86/kernel/process_64.c | 2 + > arch/x86/kernel/shstk.c | 446 ++++++++++++++++++ > arch/x86/kernel/signal.c | 13 + > arch/x86/kernel/signal_compat.c | 2 +- > arch/x86/kernel/traps.c | 62 +++ > arch/x86/mm/fault.c | 19 + > arch/x86/mm/mmap.c | 48 ++ > arch/x86/mm/pat/set_memory.c | 2 +- > arch/x86/mm/pgtable.c | 25 + > drivers/gpu/drm/i915/gvt/gtt.c | 2 +- > fs/aio.c | 2 +- > fs/proc/task_mmu.c | 3 + > include/linux/mm.h | 19 +- > include/linux/pgtable.h | 8 + > include/linux/syscalls.h | 1 + > include/uapi/asm-generic/siginfo.h | 3 +- > include/uapi/asm-generic/unistd.h | 2 +- > ipc/shm.c | 2 +- > kernel/sys_ni.c | 1 + > mm/gup.c | 16 +- > mm/huge_memory.c | 27 +- > mm/memory.c | 5 +- > mm/migrate.c | 3 +- > mm/mmap.c | 15 +- > mm/mprotect.c | 9 +- > mm/nommu.c | 4 +- > mm/util.c | 2 +- > tools/testing/selftests/x86/Makefile | 9 +- > .../selftests/x86/test_map_shadow_stack.c | 75 +++ > 69 files changed, 1797 insertions(+), 92 deletions(-) > create mode 100644 Documentation/x86/cet.rst > create mode 100644 arch/x86/include/asm/cet.h > create mode 100644 arch/x86/include/asm/mman.h > create mode 100644 arch/x86/kernel/elf_feature_prctl.c > create mode 100644 arch/x86/kernel/shstk.c > create mode 100644 tools/testing/selftests/x86/test_map_shadow_stack.c >=20 >=20 > base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 > --=20 > 2.17.1 --=20 Sincerely yours, Mike.