From: Andy Lutomirski <luto@amacapital.net> To: Dave Hansen <dave.hansen@intel.com> Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>, 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>, 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>, "Ravi V. Shankar" <ravi.v.shankar@intel.com>, Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>, Dave Martin <Dave.Martin@arm.com> Subject: Re: [PATCH v7 04/27] x86/fpu/xstate: Introduce XSAVES system states Date: Thu, 6 Jun 2019 18:54:56 -0700 [thread overview] Message-ID: <2F0417F1-DA1E-4632-AFA2-757C09B3C4B4@amacapital.net> (raw) In-Reply-To: <4effb749-0cdc-6a49-6352-7b2d4aa7d866@intel.com> > On Jun 6, 2019, at 3:08 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > > > On 6/6/19 3:04 PM, Andy Lutomirski wrote: >>> But, that seems broken. If we have supervisor state, we can't >>> always defer the load until return to userspace, so we'll never?? >>> have TIF_NEED_FPU_LOAD. That would certainly be true for >>> cet_kernel_state. >> >> Ugh. I was sort of imagining that we would treat supervisor state > completely separately from user state. But can you maybe give > examples of exactly what you mean? I was imagining a completely separate area in memory for supervisor states. I guess this might defeat the modified optimization and is probably a bad idea. >> >>> It seems like we actually need three classes of XSAVE states: 1. >>> User state >> >> This is FPU, XMM, etc, right? > > Yep. > >>> 2. Supervisor state that affects user mode >> >> User CET? > > Yep. > >>> 3. Supervisor state that affects kernel mode >> >> Like supervisor CET? If we start doing supervisor shadow stack, the >> context switches will be real fun. We may need to handle this in >> asm. > > Yeah, that's what I was thinking. > > I have the feeling Yu-cheng's patches don't comprehend this since > Sebastian's patches went in after he started working on shadow stacks. Do we need to have TIF_LOAD_FPU mean “we need to load *some* of the xsave state”? If so, maybe a bunch of the accessors should have their interfaces reviewed to make sure they’re sill sensible. > >> Where does PKRU fit in? Maybe we can treat it as #3? > > I thought Sebastian added specific PKRU handling to make it always > eager. It's actually user state that affect kernel mode. :) Indeed. But, if we document a taxonomy of states, we should make sure it fits in. I guess it’s like supervisor CET except that user code can can also read and write it. We should probably have self tests that make sure that the correct states, and nothing else, show up in ptrace and signal states, and that trying to write supervisor CET via ptrace and sigreturn is properly rejected. Just to double check my mental model: it’s okay to XSAVES twice to the same buffer with disjoint RFBM as long as we do something intelligent with XSTATE_BV afterwards, right? Because, unless we split up the buffers, I think we will have to do this when we context switch while TIF_LOAD_FPU is set. Are there performance numbers for how the time needed to XRSTORS everything versus the time to XRSTORS supervisor CET and then separately XRSTORS the FPU? This may affect whether we want context switches to have the new task eagerly or lazily restored. Hmm. I wonder if we need some way for a selftest to reliably trigger TIF_LOAD_FPU. —Andy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: Dave Hansen <dave.hansen@intel.com> Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>, 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>, 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> Subject: Re: [PATCH v7 04/27] x86/fpu/xstate: Introduce XSAVES system states Date: Thu, 6 Jun 2019 18:54:56 -0700 [thread overview] Message-ID: <2F0417F1-DA1E-4632-AFA2-757C09B3C4B4@amacapital.net> (raw) In-Reply-To: <4effb749-0cdc-6a49-6352-7b2d4aa7d866@intel.com> > On Jun 6, 2019, at 3:08 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > > > On 6/6/19 3:04 PM, Andy Lutomirski wrote: >>> But, that seems broken. If we have supervisor state, we can't >>> always defer the load until return to userspace, so we'll never?? >>> have TIF_NEED_FPU_LOAD. That would certainly be true for >>> cet_kernel_state. >> >> Ugh. I was sort of imagining that we would treat supervisor state > completely separately from user state. But can you maybe give > examples of exactly what you mean? I was imagining a completely separate area in memory for supervisor states. I guess this might defeat the modified optimization and is probably a bad idea. >> >>> It seems like we actually need three classes of XSAVE states: 1. >>> User state >> >> This is FPU, XMM, etc, right? > > Yep. > >>> 2. Supervisor state that affects user mode >> >> User CET? > > Yep. > >>> 3. Supervisor state that affects kernel mode >> >> Like supervisor CET? If we start doing supervisor shadow stack, the >> context switches will be real fun. We may need to handle this in >> asm. > > Yeah, that's what I was thinking. > > I have the feeling Yu-cheng's patches don't comprehend this since > Sebastian's patches went in after he started working on shadow stacks. Do we need to have TIF_LOAD_FPU mean “we need to load *some* of the xsave state”? If so, maybe a bunch of the accessors should have their interfaces reviewed to make sure they’re sill sensible. > >> Where does PKRU fit in? Maybe we can treat it as #3? > > I thought Sebastian added specific PKRU handling to make it always > eager. It's actually user state that affect kernel mode. :) Indeed. But, if we document a taxonomy of states, we should make sure it fits in. I guess it’s like supervisor CET except that user code can can also read and write it. We should probably have self tests that make sure that the correct states, and nothing else, show up in ptrace and signal states, and that trying to write supervisor CET via ptrace and sigreturn is properly rejected. Just to double check my mental model: it’s okay to XSAVES twice to the same buffer with disjoint RFBM as long as we do something intelligent with XSTATE_BV afterwards, right? Because, unless we split up the buffers, I think we will have to do this when we context switch while TIF_LOAD_FPU is set. Are there performance numbers for how the time needed to XRSTORS everything versus the time to XRSTORS supervisor CET and then separately XRSTORS the FPU? This may affect whether we want context switches to have the new task eagerly or lazily restored. Hmm. I wonder if we need some way for a selftest to reliably trigger TIF_LOAD_FPU. —Andy
next prev parent reply other threads:[~2019-06-07 1:55 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-06 20:06 [PATCH v7 00/27] Control-flow Enforcement: Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 01/27] Documentation/x86: Add CET description Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 02/27] x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET) Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 03/27] x86/fpu/xstate: Change names to separate XSAVES system and user states Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 04/27] x86/fpu/xstate: Introduce XSAVES system states Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 21:18 ` Dave Hansen 2019-06-06 21:18 ` Dave Hansen 2019-06-06 22:04 ` Andy Lutomirski 2019-06-06 22:04 ` Andy Lutomirski 2019-06-06 22:08 ` Dave Hansen 2019-06-06 22:08 ` Dave Hansen 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-07 1:54 ` Andy Lutomirski [this message] 2019-06-07 1:54 ` Andy Lutomirski 2019-06-06 20:06 ` [PATCH v7 05/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:07 ` Peter Zijlstra 2019-06-07 7:07 ` Peter Zijlstra 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 06/27] x86/cet: Add control protection exception handler Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 07/27] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 08/27] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 09/27] mm/mmap: Prevent Shadow Stack VMA merges Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 10/27] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 11/27] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 12/27] drm/i915/gvt: Update _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 13/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 14/27] x86/mm: Shadow stack page fault error checking Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 15/27] mm: Handle shadow stack page fault Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:30 ` Peter Zijlstra 2019-06-07 7:30 ` Peter Zijlstra 2019-06-06 20:06 ` [PATCH v7 16/27] mm: Handle THP/HugeTLB " Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 17/27] mm: Update can_follow_write_pte/pmd for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 18/27] mm: Introduce do_mmap_locked() Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:43 ` Peter Zijlstra 2019-06-07 7:43 ` Peter Zijlstra 2019-06-07 7:47 ` Peter Zijlstra 2019-06-07 7:47 ` Peter Zijlstra 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 19/27] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 20/27] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 21/27] x86/cet/shstk: Handle signals for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:58 ` Peter Zijlstra 2019-06-07 7:58 ` Peter Zijlstra 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 18:01 ` Dave Martin 2019-06-07 18:01 ` Dave Martin 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:57 ` Dave Martin 2019-06-10 16:57 ` Dave Martin 2019-06-10 17:24 ` Florian Weimer 2019-06-10 17:24 ` Florian Weimer 2019-06-10 17:24 ` Florian Weimer 2019-06-11 11:41 ` Dave Martin 2019-06-11 11:41 ` Dave Martin 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-12 9:32 ` Dave Martin 2019-06-12 9:32 ` Dave Martin 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-13 13:26 ` Dave Martin 2019-06-13 13:26 ` Dave Martin 2019-06-17 11:08 ` Florian Weimer 2019-06-17 11:08 ` Florian Weimer 2019-06-17 11:08 ` Florian Weimer 2019-06-17 12:20 ` Thomas Gleixner 2019-06-17 12:20 ` Thomas Gleixner 2019-06-17 12:20 ` Thomas Gleixner 2019-06-18 9:12 ` Dave Martin 2019-06-18 9:12 ` Dave Martin 2019-06-18 12:41 ` Peter Zijlstra 2019-06-18 12:41 ` Peter Zijlstra 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:55 ` Peter Zijlstra 2019-06-18 12:55 ` Peter Zijlstra 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:20 ` Dave Martin 2019-06-18 16:20 ` Dave Martin 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:50 ` Dave Martin 2019-06-18 16:50 ` Dave Martin 2019-06-06 20:06 ` [PATCH v7 23/27] x86/cet/shstk: ELF header parsing of Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:54 ` Peter Zijlstra 2019-06-07 7:54 ` Peter Zijlstra 2019-06-06 20:06 ` [PATCH v7 24/27] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 25/27] mm/mmap: Add Shadow stack pages to memory accounting Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-11 17:55 ` Dave Hansen 2019-06-11 17:55 ` Dave Hansen 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 26/27] x86/cet/shstk: Add arch_prctl functions for Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 27/27] x86/cet/shstk: Add Shadow Stack instructions to opcode map Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-11-01 14:03 ` Adrian Hunter 2019-11-01 14:03 ` Adrian Hunter 2019-11-01 14:17 ` Yu-cheng Yu 2019-11-01 14:17 ` Yu-cheng Yu 2019-11-01 14:17 ` Yu-cheng Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2F0417F1-DA1E-4632-AFA2-757C09B3C4B4@amacapital.net \ --to=luto@amacapital.net \ --cc=Dave.Martin@arm.com \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=bsingharora@gmail.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=esyr@redhat.com \ --cc=fweimer@redhat.com \ --cc=gorcunov@gmail.com \ --cc=hjl.tools@gmail.com \ --cc=hpa@zytor.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mike.kravetz@oracle.com \ --cc=mingo@redhat.com \ --cc=nadav.amit@gmail.com \ --cc=oleg@redhat.com \ --cc=pavel@ucw.cz \ --cc=peterz@infradead.org \ --cc=ravi.v.shankar@intel.com \ --cc=rdunlap@infradead.org \ --cc=tglx@linutronix.de \ --cc=vedvyas.shanbhogue@intel.com \ --cc=x86@kernel.org \ --cc=yu-cheng.yu@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.