All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: yu-cheng.yu@intel.com
Cc: "the arch/x86 maintainers" <x86@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Florian Weimer <fweimer@redhat.com>,
	hjl.tools@gmail.com, Jonathan Corbet <corbet@lwn.net>,
	keescook@chromiun.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>,
	ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com
Subject: Re: [RFC PATCH v3 06/24] x86/cet: Control protection exception handler
Date: Fri, 31 Aug 2018 17:01:42 +0200	[thread overview]
Message-ID: <CAG48ez0jvsDw189=YoCCa8tmJUENeUd_ypcP5bYJ+eLMPCYCOQ@mail.gmail.com> (raw)
In-Reply-To: <20180830143904.3168-7-yu-cheng.yu@intel.com>

On Thu, Aug 30, 2018 at 4:43 PM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
> A control protection exception is triggered when a control flow transfer
> attempt violated shadow stack or indirect branch tracking constraints.
> For example, the return address for a RET instruction differs from the
> safe copy on the shadow stack; or a JMP instruction arrives at a non-
> ENDBR instruction.
>
> The control protection exception handler works in a similar way as the
> general protection fault handler.

Is there a reason why all the code in this patch isn't #ifdef'ed away
on builds that don't support CET? It looks like the CET handler is
hooked up to the IDT conditionally, but the handler code is always
built?

> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
>  arch/x86/entry/entry_64.S    |  2 +-
>  arch/x86/include/asm/traps.h |  3 ++
>  arch/x86/kernel/idt.c        |  4 +++
>  arch/x86/kernel/traps.c      | 58 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 957dfb693ecc..5f4914e988df 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1000,7 +1000,7 @@ idtentry spurious_interrupt_bug           do_spurious_interrupt_bug       has_error_code=0
>  idtentry coprocessor_error             do_coprocessor_error            has_error_code=0
>  idtentry alignment_check               do_alignment_check              has_error_code=1
>  idtentry simd_coprocessor_error                do_simd_coprocessor_error       has_error_code=0
> -
> +idtentry control_protection            do_control_protection           has_error_code=1
>
>         /*
>          * Reload gs selector with exception handling
> diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
> index 3de69330e6c5..5196050ff3d5 100644
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -26,6 +26,7 @@ asmlinkage void invalid_TSS(void);
>  asmlinkage void segment_not_present(void);
>  asmlinkage void stack_segment(void);
>  asmlinkage void general_protection(void);
> +asmlinkage void control_protection(void);
>  asmlinkage void page_fault(void);
>  asmlinkage void async_page_fault(void);
>  asmlinkage void spurious_interrupt_bug(void);
> @@ -77,6 +78,7 @@ dotraplinkage void do_stack_segment(struct pt_regs *, long);
>  dotraplinkage void do_double_fault(struct pt_regs *, long);
>  #endif
>  dotraplinkage void do_general_protection(struct pt_regs *, long);
> +dotraplinkage void do_control_protection(struct pt_regs *, long);
>  dotraplinkage void do_page_fault(struct pt_regs *, unsigned long);
>  dotraplinkage void do_spurious_interrupt_bug(struct pt_regs *, long);
>  dotraplinkage void do_coprocessor_error(struct pt_regs *, long);
> @@ -142,6 +144,7 @@ enum {
>         X86_TRAP_AC,            /* 17, Alignment Check */
>         X86_TRAP_MC,            /* 18, Machine Check */
>         X86_TRAP_XF,            /* 19, SIMD Floating-Point Exception */
> +       X86_TRAP_CP = 21,       /* 21 Control Protection Fault */
>         X86_TRAP_IRET = 32,     /* 32, IRET Exception */
>  };
>
> diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
> index 01adea278a71..2d02fdd599a2 100644
> --- a/arch/x86/kernel/idt.c
> +++ b/arch/x86/kernel/idt.c
> @@ -104,6 +104,10 @@ static const __initconst struct idt_data def_idts[] = {
>  #elif defined(CONFIG_X86_32)
>         SYSG(IA32_SYSCALL_VECTOR,       entry_INT80_32),
>  #endif
> +
> +#ifdef CONFIG_X86_INTEL_CET
> +       INTG(X86_TRAP_CP,               control_protection),
> +#endif
>  };
>
>  /*
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e6db475164ed..21a713b96148 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -578,6 +578,64 @@ do_general_protection(struct pt_regs *regs, long error_code)
>  }
>  NOKPROBE_SYMBOL(do_general_protection);
>
> +static const char *control_protection_err[] =
> +{
> +       "unknown",
> +       "near-ret",
> +       "far-ret/iret",
> +       "endbranch",
> +       "rstorssp",
> +       "setssbsy",
> +};
> +
> +/*
> + * When a control protection exception occurs, send a signal
> + * to the responsible application.  Currently, control
> + * protection is only enabled for the user mode.  This
> + * exception should not come from the kernel mode.
> + */
> +dotraplinkage void
> +do_control_protection(struct pt_regs *regs, long error_code)
> +{
> +       struct task_struct *tsk;
> +
> +       RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> +       if (notify_die(DIE_TRAP, "control protection fault", regs,
> +                      error_code, X86_TRAP_CP, SIGSEGV) == NOTIFY_STOP)
> +               return;
> +       cond_local_irq_enable(regs);
> +
> +       if (!user_mode(regs))
> +               die("kernel control protection fault", regs, error_code);
> +
> +       if (!static_cpu_has(X86_FEATURE_SHSTK) &&
> +           !static_cpu_has(X86_FEATURE_IBT))
> +               WARN_ONCE(1, "CET is disabled but got control "
> +                         "protection fault\n");
> +
> +       tsk = current;
> +       tsk->thread.error_code = error_code;
> +       tsk->thread.trap_nr = X86_TRAP_CP;
> +
> +       if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
> +           printk_ratelimit()) {
> +               unsigned int max_err;
> +
> +               max_err = ARRAY_SIZE(control_protection_err) - 1;
> +               if ((error_code < 0) || (error_code > max_err))
> +                       error_code = 0;
> +               pr_info("%s[%d] control protection ip:%lx sp:%lx error:%lx(%s)",
> +                       tsk->comm, task_pid_nr(tsk),
> +                       regs->ip, regs->sp, error_code,
> +                       control_protection_err[error_code]);
> +               print_vma_addr(" in ", regs->ip);

Shouldn't this be using KERN_CONT, like other callers of
print_vma_addr(), to get the desired output?

> +               pr_cont("\n");
> +       }
> +
> +       force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk);

WARNING: multiple messages have this Message-ID (diff)
From: Jann Horn <jannh@google.com>
To: yu-cheng.yu@intel.com
Cc: the arch/x86 maintainers <x86@kernel.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Balbir Singh <bsingharora@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Florian Weimer <fweimer@redhat.com>,
	hjl.tools@gmail.com, Jonathan Corbet <corbet@lwn.net>,
	keescook@chromiun.org, Mike Kravetz <mike.kravetz@oracle.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>Pavel Machek <pa>
Subject: Re: [RFC PATCH v3 06/24] x86/cet: Control protection exception handler
Date: Fri, 31 Aug 2018 17:01:42 +0200	[thread overview]
Message-ID: <CAG48ez0jvsDw189=YoCCa8tmJUENeUd_ypcP5bYJ+eLMPCYCOQ@mail.gmail.com> (raw)
In-Reply-To: <20180830143904.3168-7-yu-cheng.yu@intel.com>

On Thu, Aug 30, 2018 at 4:43 PM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>
> A control protection exception is triggered when a control flow transfer
> attempt violated shadow stack or indirect branch tracking constraints.
> For example, the return address for a RET instruction differs from the
> safe copy on the shadow stack; or a JMP instruction arrives at a non-
> ENDBR instruction.
>
> The control protection exception handler works in a similar way as the
> general protection fault handler.

Is there a reason why all the code in this patch isn't #ifdef'ed away
on builds that don't support CET? It looks like the CET handler is
hooked up to the IDT conditionally, but the handler code is always
built?

> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
>  arch/x86/entry/entry_64.S    |  2 +-
>  arch/x86/include/asm/traps.h |  3 ++
>  arch/x86/kernel/idt.c        |  4 +++
>  arch/x86/kernel/traps.c      | 58 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 957dfb693ecc..5f4914e988df 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1000,7 +1000,7 @@ idtentry spurious_interrupt_bug           do_spurious_interrupt_bug       has_error_code=0
>  idtentry coprocessor_error             do_coprocessor_error            has_error_code=0
>  idtentry alignment_check               do_alignment_check              has_error_code=1
>  idtentry simd_coprocessor_error                do_simd_coprocessor_error       has_error_code=0
> -
> +idtentry control_protection            do_control_protection           has_error_code=1
>
>         /*
>          * Reload gs selector with exception handling
> diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
> index 3de69330e6c5..5196050ff3d5 100644
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -26,6 +26,7 @@ asmlinkage void invalid_TSS(void);
>  asmlinkage void segment_not_present(void);
>  asmlinkage void stack_segment(void);
>  asmlinkage void general_protection(void);
> +asmlinkage void control_protection(void);
>  asmlinkage void page_fault(void);
>  asmlinkage void async_page_fault(void);
>  asmlinkage void spurious_interrupt_bug(void);
> @@ -77,6 +78,7 @@ dotraplinkage void do_stack_segment(struct pt_regs *, long);
>  dotraplinkage void do_double_fault(struct pt_regs *, long);
>  #endif
>  dotraplinkage void do_general_protection(struct pt_regs *, long);
> +dotraplinkage void do_control_protection(struct pt_regs *, long);
>  dotraplinkage void do_page_fault(struct pt_regs *, unsigned long);
>  dotraplinkage void do_spurious_interrupt_bug(struct pt_regs *, long);
>  dotraplinkage void do_coprocessor_error(struct pt_regs *, long);
> @@ -142,6 +144,7 @@ enum {
>         X86_TRAP_AC,            /* 17, Alignment Check */
>         X86_TRAP_MC,            /* 18, Machine Check */
>         X86_TRAP_XF,            /* 19, SIMD Floating-Point Exception */
> +       X86_TRAP_CP = 21,       /* 21 Control Protection Fault */
>         X86_TRAP_IRET = 32,     /* 32, IRET Exception */
>  };
>
> diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
> index 01adea278a71..2d02fdd599a2 100644
> --- a/arch/x86/kernel/idt.c
> +++ b/arch/x86/kernel/idt.c
> @@ -104,6 +104,10 @@ static const __initconst struct idt_data def_idts[] = {
>  #elif defined(CONFIG_X86_32)
>         SYSG(IA32_SYSCALL_VECTOR,       entry_INT80_32),
>  #endif
> +
> +#ifdef CONFIG_X86_INTEL_CET
> +       INTG(X86_TRAP_CP,               control_protection),
> +#endif
>  };
>
>  /*
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e6db475164ed..21a713b96148 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -578,6 +578,64 @@ do_general_protection(struct pt_regs *regs, long error_code)
>  }
>  NOKPROBE_SYMBOL(do_general_protection);
>
> +static const char *control_protection_err[] =
> +{
> +       "unknown",
> +       "near-ret",
> +       "far-ret/iret",
> +       "endbranch",
> +       "rstorssp",
> +       "setssbsy",
> +};
> +
> +/*
> + * When a control protection exception occurs, send a signal
> + * to the responsible application.  Currently, control
> + * protection is only enabled for the user mode.  This
> + * exception should not come from the kernel mode.
> + */
> +dotraplinkage void
> +do_control_protection(struct pt_regs *regs, long error_code)
> +{
> +       struct task_struct *tsk;
> +
> +       RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> +       if (notify_die(DIE_TRAP, "control protection fault", regs,
> +                      error_code, X86_TRAP_CP, SIGSEGV) == NOTIFY_STOP)
> +               return;
> +       cond_local_irq_enable(regs);
> +
> +       if (!user_mode(regs))
> +               die("kernel control protection fault", regs, error_code);
> +
> +       if (!static_cpu_has(X86_FEATURE_SHSTK) &&
> +           !static_cpu_has(X86_FEATURE_IBT))
> +               WARN_ONCE(1, "CET is disabled but got control "
> +                         "protection fault\n");
> +
> +       tsk = current;
> +       tsk->thread.error_code = error_code;
> +       tsk->thread.trap_nr = X86_TRAP_CP;
> +
> +       if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
> +           printk_ratelimit()) {
> +               unsigned int max_err;
> +
> +               max_err = ARRAY_SIZE(control_protection_err) - 1;
> +               if ((error_code < 0) || (error_code > max_err))
> +                       error_code = 0;
> +               pr_info("%s[%d] control protection ip:%lx sp:%lx error:%lx(%s)",
> +                       tsk->comm, task_pid_nr(tsk),
> +                       regs->ip, regs->sp, error_code,
> +                       control_protection_err[error_code]);
> +               print_vma_addr(" in ", regs->ip);

Shouldn't this be using KERN_CONT, like other callers of
print_vma_addr(), to get the desired output?

> +               pr_cont("\n");
> +       }
> +
> +       force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk);

  reply	other threads:[~2018-08-31 15:02 UTC|newest]

Thread overview: 167+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 14:38 [RFC PATCH v3 00/24] Control Flow Enforcement: Shadow Stack Yu-cheng Yu
2018-08-30 14:38 ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 01/24] x86/cpufeatures: Add CPUIDs for Control-flow Enforcement Technology (CET) Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 02/24] x86/fpu/xstate: Change some names to separate XSAVES system and user states Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 03/24] x86/fpu/xstate: Enable XSAVES system states Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 04/24] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 05/24] Documentation/x86: Add CET description Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 20:39   ` Pavel Machek
2018-08-30 20:39     ` Pavel Machek
2018-08-30 22:49     ` Yu-cheng Yu
2018-08-30 22:49       ` Yu-cheng Yu
2018-08-30 22:49       ` Yu-cheng Yu
2018-09-14 21:17     ` Yu-cheng Yu
2018-09-14 21:17       ` Yu-cheng Yu
2018-09-14 21:17       ` Yu-cheng Yu
2018-09-03  2:56   ` Randy Dunlap
2018-09-03  2:56     ` Randy Dunlap
2018-08-30 14:38 ` [RFC PATCH v3 06/24] x86/cet: Control protection exception handler Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-31 15:01   ` Jann Horn [this message]
2018-08-31 15:01     ` Jann Horn
2018-08-31 16:20     ` Yu-cheng Yu
2018-08-31 16:20       ` Yu-cheng Yu
2018-08-31 16:20       ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 07/24] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 08/24] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 09/24] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 10/24] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 11/24] drm/i915/gvt: Update _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 12/24] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 15:49   ` Jann Horn
2018-08-30 15:49     ` Jann Horn
2018-08-30 16:02     ` Yu-cheng Yu
2018-08-30 16:02       ` Yu-cheng Yu
2018-08-30 16:02       ` Yu-cheng Yu
2018-08-30 16:08     ` Dave Hansen
2018-08-30 16:08       ` Dave Hansen
2018-08-30 16:23       ` Jann Horn
2018-08-30 16:23         ` Jann Horn
2018-08-30 17:19         ` Dave Hansen
2018-08-30 17:19           ` Dave Hansen
2018-08-30 17:26           ` Yu-cheng Yu
2018-08-30 17:26             ` Yu-cheng Yu
2018-08-30 17:26             ` Yu-cheng Yu
2018-08-30 17:33             ` Dave Hansen
2018-08-30 17:33               ` Dave Hansen
2018-08-30 17:54               ` Yu-cheng Yu
2018-08-30 17:54                 ` Yu-cheng Yu
2018-08-30 17:54                 ` Yu-cheng Yu
2018-08-30 17:59                 ` Jann Horn
2018-08-30 17:59                   ` Jann Horn
2018-08-30 20:21                   ` Yu-cheng Yu
2018-08-30 20:21                     ` Yu-cheng Yu
2018-08-30 20:21                     ` Yu-cheng Yu
2018-08-30 20:44                     ` Jann Horn
2018-08-30 20:44                       ` Jann Horn
2018-08-30 20:52                       ` Yu-cheng Yu
2018-08-30 20:52                         ` Yu-cheng Yu
2018-08-30 20:52                         ` Yu-cheng Yu
2018-08-30 21:01                         ` Jann Horn
2018-08-30 21:01                           ` Jann Horn
2018-08-30 21:47                           ` Jann Horn
2018-08-30 21:47                             ` Jann Horn
2018-08-31  9:53                             ` Peter Zijlstra
2018-08-31  9:53                               ` Peter Zijlstra
2018-08-31 14:33                               ` Yu-cheng Yu
2018-08-31 14:33                                 ` Yu-cheng Yu
2018-08-31 14:33                                 ` Yu-cheng Yu
2018-08-31 14:47                                 ` Dave Hansen
2018-08-31 14:47                                   ` Dave Hansen
2018-08-31 15:48                                   ` Yu-cheng Yu
2018-08-31 15:48                                     ` Yu-cheng Yu
2018-08-31 15:48                                     ` Yu-cheng Yu
2018-08-31 15:58                                     ` Dave Hansen
2018-08-31 15:58                                       ` Dave Hansen
2018-08-31 16:29                                       ` Peter Zijlstra
2018-08-31 16:29                                         ` Peter Zijlstra
2018-09-14 20:39                                         ` Yu-cheng Yu
2018-09-14 20:39                                           ` Yu-cheng Yu
2018-09-14 20:39                                           ` Yu-cheng Yu
2018-09-14 20:46                                           ` Dave Hansen
2018-09-14 20:46                                             ` Dave Hansen
2018-09-14 20:46                                             ` Dave Hansen
2018-09-14 21:08                                             ` Yu-cheng Yu
2018-09-14 21:08                                               ` Yu-cheng Yu
2018-09-14 21:08                                               ` Yu-cheng Yu
2018-09-14 21:33                                               ` Dave Hansen
2018-09-14 21:33                                                 ` Dave Hansen
2018-09-14 21:33                                                 ` Dave Hansen
2018-08-31  1:23                   ` Andy Lutomirski
2018-08-31  1:23                     ` Andy Lutomirski
2018-08-30 17:34           ` Andy Lutomirski
2018-08-30 17:34             ` Andy Lutomirski
2018-08-30 18:55             ` Dave Hansen
2018-08-30 18:55               ` Dave Hansen
2018-08-31 17:46               ` Andy Lutomirski
2018-08-31 17:46                 ` Andy Lutomirski
2018-08-31 17:52                 ` Dave Hansen
2018-08-31 17:52                   ` Dave Hansen
2018-08-31 17:52                   ` Dave Hansen
2018-08-30 19:59   ` Randy Dunlap
2018-08-30 19:59     ` Randy Dunlap
2018-08-30 20:23     ` Yu-cheng Yu
2018-08-30 20:23       ` Yu-cheng Yu
2018-08-30 20:23       ` Yu-cheng Yu
2018-08-31 16:29   ` Dave Hansen
2018-08-31 16:29     ` Dave Hansen
2018-08-30 14:38 ` [RFC PATCH v3 13/24] x86/mm: Shadow stack page fault error checking Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 14/24] mm: Handle shadow stack page fault Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 15/24] mm: Handle THP/HugeTLB " Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 16/24] mm: Update can_follow_write_pte/pmd for shadow stack Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 17/24] mm: Introduce do_mmap_locked() Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 18/24] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 16:10   ` Jann Horn
2018-08-30 16:10     ` Jann Horn
2018-08-30 16:20     ` Yu-cheng Yu
2018-08-30 16:20       ` Yu-cheng Yu
2018-08-30 16:20       ` Yu-cheng Yu
2018-08-30 14:38 ` [RFC PATCH v3 19/24] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu
2018-08-30 14:38   ` Yu-cheng Yu
2018-08-30 15:39   ` Jann Horn
2018-08-30 15:39     ` Jann Horn
2018-08-30 15:55     ` Andy Lutomirski
2018-08-30 15:55       ` Andy Lutomirski
2018-08-30 16:22       ` Yu-cheng Yu
2018-08-30 16:22         ` Yu-cheng Yu
2018-08-30 16:22         ` Yu-cheng Yu
2018-08-31 21:49         ` Yu-cheng Yu
2018-08-31 21:49           ` Yu-cheng Yu
2018-08-31 21:49           ` Yu-cheng Yu
2018-08-31 22:16           ` Andy Lutomirski
2018-08-31 22:16             ` Andy Lutomirski
2018-09-14 20:46             ` Yu-cheng Yu
2018-09-14 20:46               ` Yu-cheng Yu
2018-09-14 20:46               ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 20/24] x86/cet/shstk: Signal handling for shadow stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 21/24] x86/cet/shstk: ELF header parsing of Shadow Stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 22/24] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 23/24] x86/cet/shstk: Add arch_prctl functions for Shadow Stack Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-08-30 14:39 ` [RFC PATCH v3 24/24] x86/cet/shstk: Add Shadow Stack instructions to opcode map Yu-cheng Yu
2018-08-30 14:39   ` Yu-cheng Yu
2018-09-02  8:13 ` [RFC PATCH v3 00/24] Control Flow Enforcement: Shadow Stack Balbir Singh
2018-09-02  8:13   ` Balbir Singh
2018-09-04 14:47   ` Yu-cheng Yu
2018-09-04 14:47     ` Yu-cheng Yu
2018-09-04 14:47     ` 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='CAG48ez0jvsDw189=YoCCa8tmJUENeUd_ypcP5bYJ+eLMPCYCOQ@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=arnd@arndb.de \
    --cc=bsingharora@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=fweimer@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromiun.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=luto@amacapital.net \
    --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=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: link
Be 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.