From: Ingo Molnar <mingo@kernel.org> To: David Woodhouse <dwmw2@infradead.org> Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "KarimAllah Ahmed" <karahmed@amazon.de>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Andi Kleen" <ak@linux.intel.com>, "Andrea Arcangeli" <aarcange@redhat.com>, "Andy Lutomirski" <luto@kernel.org>, "Arjan van de Ven" <arjan@linux.intel.com>, "Ashok Raj" <ashok.raj@intel.com>, "Asit Mallick" <asit.k.mallick@intel.com>, "Borislav Petkov" <bp@suse.de>, "Dan Williams" <dan.j.williams@intel.com>, "Dave Hansen" <dave.hansen@intel.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "H . Peter Anvin" <hpa@zytor.com>, "Ingo Molnar" <mingo@redhat.com>, "Janakarajan Natarajan" <Janakarajan.Natarajan@amd.com>, "Joerg Roedel" <joro@8bytes.org>, "Jun Nakajima" <jun.nakajima@intel.com>, "Laura Abbott" <labbott@redhat.com>, "Masami Hiramatsu" <mhiramat@kernel.org>, "Paolo Bonzini" <pbonzini@redhat.com>, "Peter Zijlstra" <peterz@infradead.org>, "Radim Krčmář" <rkrcmar@redhat.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Tim Chen" <tim.c.chen@linux.intel.com>, "Tom Lendacky" <thomas.lendacky@amd.com>, "KVM list" <kvm@vger.kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, "Arjan Van De Ven" <arjan.van.de.ven@intel.com> Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Date: Tue, 23 Jan 2018 08:53:58 +0100 [thread overview] Message-ID: <20180123075358.nztpyxympwfkyi2a@gmail.com> (raw) In-Reply-To: <20180123072930.soz25cyky3u4hpgv@gmail.com> * Ingo Molnar <mingo@kernel.org> wrote: > * David Woodhouse <dwmw2@infradead.org> wrote: > > > But wait, why did I say "mostly"? Well, not everyone has a retpoline > > compiler yet... but OK, screw them; they need to update. > > > > Then there's Skylake, and that generation of CPU cores. For complicated > > reasons they actually end up being vulnerable not just on indirect > > branches, but also on a 'ret' in some circumstances (such as 16+ CALLs > > in a deep chain). > > > > The IBRS solution, ugly though it is, did address that. Retpoline > > doesn't. There are patches being floated to detect and prevent deep > > stacks, and deal with some of the other special cases that bite on SKL, > > but those are icky too. And in fact IBRS performance isn't anywhere > > near as bad on this generation of CPUs as it is on earlier CPUs > > *anyway*, which makes it not quite so insane to *contemplate* using it > > as Intel proposed. > > There's another possible method to avoid deep stacks on Skylake, without compiler > support: > > - Use the existing mcount based function tracing live patching machinery > (CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth > tracking tracer which would issue a retpoline when stack depth crosses > boundaries of ~16 entries. The patch below demonstrates the principle, it forcibly enables dynamic ftrace patching (CONFIG_DYNAMIC_FTRACE=y et al) and turns mcount/__fentry__ into a RET: ffffffff81a01a40 <__fentry__>: ffffffff81a01a40: c3 retq This would have to be extended with (very simple) call stack depth tracking (just 3 more instructions would do in the fast path I believe) and a suitable SkyLake workaround (and also has to play nice with the ftrace callbacks). On non-SkyLake the overhead would be 0 cycles. On SkyLake this would add an overhead of maybe 2-3 cycles per function call and obviously all this code and data would be very cache hot. Given that the average number of function calls per system call is around a dozen, this would be _much_ faster than any microcode/MSR based approach. Is there a testcase for the SkyLake 16-deep-call-stack problem that I could run? Is there a description of the exact speculative execution vulnerability that has to be addressed to begin with? If this approach is workable I'd much prefer it to any MSR writes in the syscall entry path not just because it's fast enough in practice to not be turned off by everyone, but also because everyone would agree that per function call overhead needs to go away on new CPUs. Both deployment and backporting is also _much_ more flexible, simpler, faster and more complete than microcode/firmware or compiler based solutions. Assuming the vulnerability can be addressed via this route that is, which is a big assumption! Thanks, Ingo arch/x86/Kconfig | 3 +++ arch/x86/kernel/ftrace_64.S | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 423e4b64e683..df471538a79c 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -133,6 +133,8 @@ config X86 select HAVE_DMA_CONTIGUOUS select HAVE_DYNAMIC_FTRACE select HAVE_DYNAMIC_FTRACE_WITH_REGS + select DYNAMIC_FTRACE + select DYNAMIC_FTRACE_WITH_REGS select HAVE_EBPF_JIT if X86_64 select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_EXIT_THREAD @@ -140,6 +142,7 @@ config X86 select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER + select FUNCTION_TRACER select HAVE_GCC_PLUGINS select HAVE_HW_BREAKPOINT select HAVE_IDE diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 7cb8ba08beb9..1e219e0f2887 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -19,6 +19,7 @@ EXPORT_SYMBOL(__fentry__) # define function_hook mcount EXPORT_SYMBOL(mcount) #endif + ret /* All cases save the original rbp (8 bytes) */ #ifdef CONFIG_FRAME_POINTER
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org> To: David Woodhouse <dwmw2@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org>, KarimAllah Ahmed <karahmed@amazon.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Andi Kleen <ak@linux.intel.com>, Andrea Arcangeli <aarcange@redhat.com>, Andy Lutomirski <luto@kernel.org>, Arjan van de Ven <arjan@linux.intel.com>, Ashok Raj <ashok.raj@intel.com>, Asit Mallick <asit.k.mallick@intel.com>, Borislav Petkov <bp@suse.de>, Dan Williams <dan.j.williams@intel.com>, Dave Hansen <dave.hansen@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>, Joerg Roedel <joro@8bytes.org>, Jun Nakajima <jun.nakajima@intel.com>, Laura Abbott <labbott@redhat.com>, Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Date: Tue, 23 Jan 2018 08:53:58 +0100 [thread overview] Message-ID: <20180123075358.nztpyxympwfkyi2a@gmail.com> (raw) In-Reply-To: <20180123072930.soz25cyky3u4hpgv@gmail.com> * Ingo Molnar <mingo@kernel.org> wrote: > * David Woodhouse <dwmw2@infradead.org> wrote: > > > But wait, why did I say "mostly"? Well, not everyone has a retpoline > > compiler yet... but OK, screw them; they need to update. > > > > Then there's Skylake, and that generation of CPU cores. For complicated > > reasons they actually end up being vulnerable not just on indirect > > branches, but also on a 'ret' in some circumstances (such as 16+ CALLs > > in a deep chain). > > > > The IBRS solution, ugly though it is, did address that. Retpoline > > doesn't. There are patches being floated to detect and prevent deep > > stacks, and deal with some of the other special cases that bite on SKL, > > but those are icky too. And in fact IBRS performance isn't anywhere > > near as bad on this generation of CPUs as it is on earlier CPUs > > *anyway*, which makes it not quite so insane to *contemplate* using it > > as Intel proposed. > > There's another possible method to avoid deep stacks on Skylake, without compiler > support: > > - Use the existing mcount based function tracing live patching machinery > (CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth > tracking tracer which would issue a retpoline when stack depth crosses > boundaries of ~16 entries. The patch below demonstrates the principle, it forcibly enables dynamic ftrace patching (CONFIG_DYNAMIC_FTRACE=y et al) and turns mcount/__fentry__ into a RET: ffffffff81a01a40 <__fentry__>: ffffffff81a01a40: c3 retq This would have to be extended with (very simple) call stack depth tracking (just 3 more instructions would do in the fast path I believe) and a suitable SkyLake workaround (and also has to play nice with the ftrace callbacks). On non-SkyLake the overhead would be 0 cycles. On SkyLake this would add an overhead of maybe 2-3 cycles per function call and obviously all this code and data would be very cache hot. Given that the average number of function calls per system call is around a dozen, this would be _much_ faster than any microcode/MSR based approach. Is there a testcase for the SkyLake 16-deep-call-stack problem that I could run? Is there a description of the exact speculative execution vulnerability that has to be addressed to begin with? If this approach is workable I'd much prefer it to any MSR writes in the syscall entry path not just because it's fast enough in practice to not be turned off by everyone, but also because everyone would agree that per function call overhead needs to go away on new CPUs. Both deployment and backporting is also _much_ more flexible, simpler, faster and more complete than microcode/firmware or compiler based solutions. Assuming the vulnerability can be addressed via this route that is, which is a big assumption! Thanks, Ingo arch/x86/Kconfig | 3 +++ arch/x86/kernel/ftrace_64.S | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 423e4b64e683..df471538a79c 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -133,6 +133,8 @@ config X86 select HAVE_DMA_CONTIGUOUS select HAVE_DYNAMIC_FTRACE select HAVE_DYNAMIC_FTRACE_WITH_REGS + select DYNAMIC_FTRACE + select DYNAMIC_FTRACE_WITH_REGS select HAVE_EBPF_JIT if X86_64 select HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_EXIT_THREAD @@ -140,6 +142,7 @@ config X86 select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER + select FUNCTION_TRACER select HAVE_GCC_PLUGINS select HAVE_HW_BREAKPOINT select HAVE_IDE diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 7cb8ba08beb9..1e219e0f2887 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -19,6 +19,7 @@ EXPORT_SYMBOL(__fentry__) # define function_hook mcount EXPORT_SYMBOL(mcount) #endif + ret /* All cases save the original rbp (8 bytes) */ #ifdef CONFIG_FRAME_POINTER
next prev parent reply other threads:[~2018-01-23 7:53 UTC|newest] Thread overview: 311+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-20 19:22 [RFC 00/10] Speculation Control feature support KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:22 ` [RFC 01/10] x86/speculation: Add basic support for IBPB KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:22 ` [RFC 02/10] x86/kvm: Add IBPB support KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 20:18 ` Woodhouse, David 2018-01-20 20:18 ` Woodhouse, David 2018-01-22 18:56 ` Jim Mattson 2018-01-22 18:56 ` Jim Mattson 2018-01-22 19:31 ` Jim Mattson 2018-01-22 19:31 ` Jim Mattson 2018-01-20 19:22 ` [RFC 03/10] x86/speculation: Use Indirect Branch Prediction Barrier in context switch KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:22 ` [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 21:06 ` Woodhouse, David 2018-01-20 21:06 ` Woodhouse, David 2018-01-22 18:29 ` Tim Chen 2018-01-22 18:29 ` Tim Chen 2018-01-21 11:22 ` Peter Zijlstra 2018-01-21 11:22 ` Peter Zijlstra 2018-01-21 12:04 ` David Woodhouse 2018-01-21 12:04 ` David Woodhouse 2018-01-21 14:07 ` H.J. Lu 2018-01-21 14:07 ` H.J. Lu 2018-01-22 10:19 ` Peter Zijlstra 2018-01-22 10:19 ` Peter Zijlstra 2018-01-22 10:23 ` David Woodhouse 2018-01-22 10:23 ` David Woodhouse 2018-01-21 16:21 ` Ingo Molnar 2018-01-21 16:21 ` Ingo Molnar 2018-01-21 16:25 ` Arjan van de Ven 2018-01-21 16:25 ` Arjan van de Ven 2018-01-21 22:20 ` Woodhouse, David 2018-01-21 22:20 ` Woodhouse, David 2018-01-29 6:35 ` Jon Masters 2018-01-29 6:35 ` Jon Masters 2018-01-29 14:07 ` Peter Zijlstra 2018-01-29 14:07 ` Peter Zijlstra 2018-01-20 19:22 ` [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-21 14:31 ` Thomas Gleixner 2018-01-21 14:31 ` Thomas Gleixner 2018-01-21 14:56 ` Borislav Petkov 2018-01-21 14:56 ` Borislav Petkov 2018-01-22 9:51 ` Peter Zijlstra 2018-01-22 9:51 ` Peter Zijlstra 2018-01-22 12:06 ` Borislav Petkov 2018-01-22 12:06 ` Borislav Petkov 2018-01-22 13:30 ` Greg Kroah-Hartman 2018-01-22 13:30 ` Greg Kroah-Hartman 2018-01-22 13:36 ` Woodhouse, David 2018-01-22 13:37 ` Woodhouse, David 2018-01-21 15:25 ` David Woodhouse 2018-01-21 15:25 ` David Woodhouse 2018-01-23 20:58 ` David Woodhouse 2018-01-23 20:58 ` David Woodhouse 2018-01-23 22:43 ` Johannes Erdfelt 2018-01-24 8:47 ` Peter Zijlstra 2018-01-24 8:47 ` Peter Zijlstra 2018-01-24 9:02 ` David Woodhouse 2018-01-24 9:02 ` David Woodhouse 2018-01-24 9:10 ` Greg Kroah-Hartman 2018-01-24 9:10 ` Greg Kroah-Hartman 2018-01-24 15:09 ` Arjan van de Ven 2018-01-24 15:09 ` Arjan van de Ven 2018-01-24 15:18 ` David Woodhouse 2018-01-24 15:18 ` David Woodhouse 2018-01-24 9:34 ` Peter Zijlstra 2018-01-24 9:34 ` Peter Zijlstra 2018-01-24 10:49 ` Henrique de Moraes Holschuh 2018-01-24 10:49 ` Henrique de Moraes Holschuh 2018-01-24 12:30 ` David Woodhouse 2018-01-24 12:30 ` David Woodhouse 2018-01-24 12:14 ` David Woodhouse 2018-01-24 12:14 ` David Woodhouse 2018-01-24 12:29 ` Peter Zijlstra 2018-01-24 12:29 ` Peter Zijlstra 2018-01-24 12:58 ` David Woodhouse 2018-01-24 12:58 ` David Woodhouse 2018-01-29 20:14 ` [RFC,05/10] " Eduardo Habkost 2018-01-29 20:14 ` Eduardo Habkost 2018-01-29 20:17 ` David Woodhouse 2018-01-29 20:17 ` David Woodhouse 2018-01-29 20:42 ` Eduardo Habkost 2018-01-29 20:42 ` Eduardo Habkost 2018-01-29 20:44 ` Arjan van de Ven 2018-01-29 20:44 ` Arjan van de Ven 2018-01-29 21:02 ` David Woodhouse 2018-01-29 21:02 ` David Woodhouse 2018-01-29 21:37 ` Jim Mattson 2018-01-29 21:37 ` Jim Mattson 2018-01-29 21:50 ` Eduardo Habkost 2018-01-29 21:50 ` Eduardo Habkost 2018-01-29 22:12 ` Jim Mattson 2018-01-29 22:12 ` Jim Mattson 2018-01-30 1:22 ` Eduardo Habkost 2018-01-30 1:22 ` Eduardo Habkost 2018-01-29 22:25 ` Andi Kleen 2018-01-29 22:25 ` Andi Kleen 2018-01-30 1:37 ` Eduardo Habkost 2018-01-30 1:37 ` Eduardo Habkost 2018-01-29 21:37 ` Andi Kleen 2018-01-29 21:37 ` Andi Kleen 2018-01-29 21:44 ` Eduardo Habkost 2018-01-29 21:44 ` Eduardo Habkost 2018-01-29 22:10 ` Konrad Rzeszutek Wilk 2018-01-29 22:10 ` Konrad Rzeszutek Wilk 2018-01-30 1:12 ` Eduardo Habkost 2018-01-30 1:12 ` Eduardo Habkost 2018-01-30 0:23 ` Linus Torvalds 2018-01-30 0:23 ` Linus Torvalds 2018-01-30 1:03 ` Jim Mattson 2018-01-30 1:03 ` Jim Mattson 2018-01-30 3:13 ` Andi Kleen 2018-01-30 3:13 ` Andi Kleen 2018-01-31 15:03 ` Paolo Bonzini 2018-01-31 15:03 ` Paolo Bonzini 2018-01-31 15:07 ` Dr. David Alan Gilbert 2018-01-31 15:07 ` Dr. David Alan Gilbert 2018-01-30 1:32 ` Arjan van de Ven 2018-01-30 1:32 ` Arjan van de Ven 2018-01-30 3:32 ` Linus Torvalds 2018-01-30 3:32 ` Linus Torvalds 2018-01-30 12:04 ` Eduardo Habkost 2018-01-30 12:04 ` Eduardo Habkost 2018-01-30 13:54 ` Arjan van de Ven 2018-01-30 13:54 ` Arjan van de Ven 2018-01-30 8:22 ` David Woodhouse 2018-01-30 8:22 ` David Woodhouse 2018-01-30 11:35 ` David Woodhouse 2018-01-30 11:35 ` David Woodhouse 2018-01-30 11:56 ` Dr. David Alan Gilbert 2018-01-30 11:56 ` Dr. David Alan Gilbert 2018-01-30 12:11 ` Christian Borntraeger 2018-01-30 12:11 ` Christian Borntraeger 2018-01-30 14:46 ` Christophe de Dinechin 2018-01-30 14:46 ` Christophe de Dinechin 2018-01-30 14:52 ` Christian Borntraeger 2018-01-30 14:52 ` Christian Borntraeger 2018-01-30 14:56 ` Christophe de Dinechin 2018-01-30 14:56 ` Christophe de Dinechin 2018-01-30 15:33 ` Christian Borntraeger 2018-01-30 15:33 ` Christian Borntraeger 2018-01-30 20:46 ` Alan Cox 2018-01-30 20:46 ` Alan Cox 2018-01-31 10:05 ` Christophe de Dinechin 2018-01-31 10:05 ` Christophe de Dinechin 2018-01-31 10:15 ` Thomas Gleixner 2018-01-31 10:15 ` Thomas Gleixner 2018-01-31 11:04 ` Dr. David Alan Gilbert 2018-01-31 11:04 ` Dr. David Alan Gilbert 2018-01-31 11:52 ` Borislav Petkov 2018-01-31 11:52 ` Borislav Petkov 2018-01-31 12:30 ` Dr. David Alan Gilbert 2018-01-31 12:30 ` Dr. David Alan Gilbert 2018-01-31 13:18 ` Borislav Petkov 2018-01-31 13:18 ` Borislav Petkov 2018-01-31 14:04 ` Dr. David Alan Gilbert 2018-01-31 14:04 ` Dr. David Alan Gilbert 2018-01-31 14:44 ` Eduardo Habkost 2018-01-31 14:44 ` Eduardo Habkost 2018-01-31 16:28 ` Borislav Petkov 2018-01-31 16:28 ` Borislav Petkov 2018-01-31 11:07 ` Christophe de Dinechin 2018-01-31 11:07 ` Christophe de Dinechin 2018-01-31 15:00 ` Eduardo Habkost 2018-01-31 15:00 ` Eduardo Habkost 2018-01-31 15:11 ` Arjan van de Ven 2018-01-31 15:11 ` Arjan van de Ven 2018-01-31 10:03 ` [RFC 05/10] " Christophe de Dinechin 2018-01-31 10:03 ` Christophe de Dinechin 2018-01-20 19:22 ` [RFC 06/10] x86/speculation: Add inlines to control Indirect Branch Speculation KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:22 ` [RFC 07/10] x86: Simplify spectre_v2 command line parsing KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:22 ` [RFC 08/10] x86/idle: Control Indirect Branch Speculation in idle KarimAllah Ahmed 2018-01-20 19:22 ` KarimAllah Ahmed 2018-01-20 19:23 ` [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation KarimAllah Ahmed 2018-01-20 19:23 ` KarimAllah Ahmed 2018-01-21 19:14 ` Andy Lutomirski 2018-01-21 19:14 ` Andy Lutomirski 2018-01-23 16:12 ` Tom Lendacky 2018-01-23 16:12 ` Tom Lendacky 2018-01-23 16:20 ` Woodhouse, David 2018-01-23 16:20 ` Woodhouse, David 2018-01-23 22:37 ` Tom Lendacky 2018-01-23 22:37 ` Tom Lendacky 2018-01-23 22:49 ` Andi Kleen 2018-01-23 22:49 ` Andi Kleen 2018-01-23 23:14 ` Woodhouse, David 2018-01-23 23:14 ` Woodhouse, David 2018-01-23 23:22 ` Andi Kleen 2018-01-23 23:22 ` Andi Kleen 2018-01-24 0:47 ` Tim Chen 2018-01-24 0:47 ` Tim Chen 2018-01-24 1:00 ` Andy Lutomirski 2018-01-24 1:00 ` Andy Lutomirski 2018-01-24 1:22 ` David Woodhouse 2018-01-24 1:22 ` David Woodhouse 2018-01-24 1:59 ` Van De Ven, Arjan 2018-01-24 1:59 ` Van De Ven, Arjan 2018-01-24 3:25 ` Andy Lutomirski 2018-01-24 3:25 ` Andy Lutomirski 2018-01-21 19:34 ` Linus Torvalds 2018-01-21 20:28 ` David Woodhouse 2018-01-21 20:28 ` David Woodhouse 2018-01-21 21:35 ` Linus Torvalds 2018-01-21 21:35 ` Linus Torvalds 2018-01-21 22:00 ` David Woodhouse 2018-01-21 22:00 ` David Woodhouse 2018-01-21 22:27 ` Linus Torvalds 2018-01-21 22:27 ` Linus Torvalds 2018-01-22 16:27 ` David Woodhouse 2018-01-22 16:27 ` David Woodhouse 2018-01-23 7:29 ` Ingo Molnar 2018-01-23 7:29 ` Ingo Molnar 2018-01-23 7:53 ` Ingo Molnar [this message] 2018-01-23 7:53 ` Ingo Molnar 2018-01-23 9:27 ` Ingo Molnar 2018-01-23 9:27 ` Ingo Molnar 2018-01-23 9:37 ` David Woodhouse 2018-01-23 9:37 ` David Woodhouse 2018-01-23 15:01 ` Dave Hansen 2018-01-23 15:01 ` Dave Hansen 2018-01-23 9:30 ` David Woodhouse 2018-01-23 9:30 ` David Woodhouse 2018-01-23 10:15 ` Ingo Molnar 2018-01-23 10:15 ` Ingo Molnar 2018-01-23 10:27 ` David Woodhouse 2018-01-23 10:27 ` David Woodhouse 2018-01-23 10:44 ` Ingo Molnar 2018-01-23 10:44 ` Ingo Molnar 2018-01-23 10:57 ` David Woodhouse 2018-01-23 10:23 ` Ingo Molnar 2018-01-23 10:23 ` Ingo Molnar 2018-01-23 10:35 ` David Woodhouse 2018-02-04 18:43 ` Thomas Gleixner 2018-02-04 18:43 ` Thomas Gleixner 2018-02-04 20:22 ` David Woodhouse 2018-02-04 20:22 ` David Woodhouse 2018-02-06 9:14 ` David Woodhouse 2018-02-06 9:14 ` David Woodhouse 2018-01-25 16:19 ` Mason 2018-01-25 16:19 ` Mason 2018-01-25 17:16 ` Greg Kroah-Hartman 2018-01-25 17:16 ` Greg Kroah-Hartman 2018-01-29 11:59 ` Mason 2018-01-29 11:59 ` Mason 2018-01-24 0:05 ` Andi Kleen 2018-01-23 20:16 ` Pavel Machek 2018-01-23 20:16 ` Pavel Machek 2018-01-20 19:23 ` [RFC 10/10] x86/enter: Use IBRS on syscall and interrupts KarimAllah Ahmed 2018-01-20 19:23 ` KarimAllah Ahmed 2018-01-21 13:50 ` Konrad Rzeszutek Wilk 2018-01-21 13:50 ` Konrad Rzeszutek Wilk 2018-01-21 14:40 ` KarimAllah Ahmed 2018-01-21 14:40 ` KarimAllah Ahmed 2018-01-21 17:22 ` Dave Hansen 2018-01-21 17:22 ` Dave Hansen 2018-01-21 14:02 ` [RFC 00/10] Speculation Control feature support Konrad Rzeszutek Wilk 2018-01-21 14:02 ` Konrad Rzeszutek Wilk 2018-01-22 21:27 ` David Woodhouse 2018-01-22 21:27 ` David Woodhouse 2018-01-22 22:15 [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Luke Kenneth Casson Leighton 2018-01-23 11:13 Liran Alon 2018-01-25 22:20 ` Dave Hansen 2018-01-26 2:11 Liran Alon 2018-01-26 2:23 ` Dave Hansen 2018-01-26 9:11 ` David Woodhouse 2018-01-26 9:11 ` David Woodhouse 2018-01-26 17:19 ` Linus Torvalds 2018-01-26 17:19 ` Linus Torvalds 2018-01-26 17:27 ` Borislav Petkov 2018-01-26 17:27 ` Borislav Petkov 2018-01-26 17:29 ` David Woodhouse 2018-01-26 17:29 ` David Woodhouse 2018-01-26 17:31 ` David Woodhouse 2018-01-26 17:31 ` David Woodhouse 2018-01-26 17:59 ` Andi Kleen 2018-01-26 17:59 ` Andi Kleen 2018-01-26 18:11 ` David Woodhouse 2018-01-26 18:11 ` David Woodhouse 2018-01-26 18:12 ` Arjan van de Ven 2018-01-26 18:12 ` Arjan van de Ven 2018-01-26 18:26 ` David Woodhouse 2018-01-26 18:26 ` David Woodhouse 2018-01-26 18:28 ` Van De Ven, Arjan 2018-01-26 18:28 ` Van De Ven, Arjan 2018-01-26 18:43 ` David Woodhouse 2018-01-26 18:43 ` David Woodhouse 2018-01-26 18:44 ` Van De Ven, Arjan 2018-01-26 18:44 ` Van De Ven, Arjan 2018-01-26 18:53 ` David Woodhouse 2018-01-26 18:53 ` David Woodhouse 2018-01-26 19:02 ` Konrad Rzeszutek Wilk 2018-01-26 19:02 ` Konrad Rzeszutek Wilk 2018-01-26 19:11 ` Hansen, Dave 2018-01-26 19:11 ` Hansen, Dave 2018-01-27 13:42 ` Konrad Rzeszutek Wilk 2018-01-27 13:42 ` Konrad Rzeszutek Wilk 2018-01-27 15:55 ` Dave Hansen 2018-01-27 15:55 ` Dave Hansen 2018-01-26 19:11 ` David Woodhouse 2018-01-26 19:11 ` David Woodhouse 2018-01-26 8:46 ` David Woodhouse 2018-01-26 8:46 ` David Woodhouse 2018-01-26 2:50 Liran Alon 2018-01-26 2:55 ` Van De Ven, Arjan 2018-01-26 2:55 ` Van De Ven, Arjan
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=20180123075358.nztpyxympwfkyi2a@gmail.com \ --to=mingo@kernel.org \ --cc=Janakarajan.Natarajan@amd.com \ --cc=aarcange@redhat.com \ --cc=ak@linux.intel.com \ --cc=arjan.van.de.ven@intel.com \ --cc=arjan@linux.intel.com \ --cc=ashok.raj@intel.com \ --cc=asit.k.mallick@intel.com \ --cc=bp@suse.de \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@intel.com \ --cc=dwmw2@infradead.org \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=joro@8bytes.org \ --cc=jun.nakajima@intel.com \ --cc=karahmed@amazon.de \ --cc=kvm@vger.kernel.org \ --cc=labbott@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mhiramat@kernel.org \ --cc=mingo@redhat.com \ --cc=pbonzini@redhat.com \ --cc=peterz@infradead.org \ --cc=rkrcmar@redhat.com \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=tim.c.chen@linux.intel.com \ --cc=torvalds@linux-foundation.org \ --cc=x86@kernel.org \ /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.