Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
On Mon, Jan 15, 2018 at 6:42 AM, Arjan van de Ven wrote: >> >> This would means that userspace would see return predictions based >> on the values the kernel 'stuffed' into the RSB to fill it. >> >> Potentially this leaks a kernel address to userspace. > > > KASLR pretty much died in May this year to be honest with the KAISER paper > (if not before then) KASLR was always on shaky ground for local attacks. For pure remote attacks, it's still useful. And for driving forward research, it appears to be quite useful. ;) -Kees -- Kees Cook Pixel Security
Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
This would means that userspace would see return predictions based on the values the kernel 'stuffed' into the RSB to fill it. Potentially this leaks a kernel address to userspace. KASLR pretty much died in May this year to be honest with the KAISER paper (if not before then) also with KPTI the address won't have a TLB mapping so it wouldn't actually be speculated into.
Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
On Mon, 2018-01-15 at 14:35 +, David Laight wrote: > From: David Woodhouse > > > > Sent: 14 January 2018 17:04 > > x86/retpoline: Fill RSB on context switch for affected CPUs > > > > On context switch from a shallow call stack to a deeper one, as the CPU > > does 'ret' up the deeper side it may encounter RSB entries (predictions for > > where the 'ret' goes to) which were populated in userspace. > > > > This is problematic if neither SMEP nor KPTI (the latter of which marks > > userspace pages as NX for the kernel) are active, as malicious code in > > userspace may then be executed speculatively. > ... > > Do we have a guarantee that all cpu actually detect the related RSB underflow? > > It wouldn't surprise me if at least some cpu just let it wrap. > > This would means that userspace would see return predictions based > on the values the kernel 'stuffed' into the RSB to fill it. > > Potentially this leaks a kernel address to userspace. Yeah, KASLR is dead unless we do a full IBPB before *every* VMLAUNCH or return to userspace anyway, isn't it? With KPTI we could put the RSB- stuffer into the syscall trampoline page perhaps... For this to be a concern for userspace, I think it does have to be true that only the lower bits are used, which adds a little complexity but probably isn't insurmountable? smime.p7s Description: S/MIME cryptographic signature
RE: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
From: David Woodhouse > Sent: 14 January 2018 17:04 > x86/retpoline: Fill RSB on context switch for affected CPUs > > On context switch from a shallow call stack to a deeper one, as the CPU > does 'ret' up the deeper side it may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. > > This is problematic if neither SMEP nor KPTI (the latter of which marks > userspace pages as NX for the kernel) are active, as malicious code in > userspace may then be executed speculatively. ... Do we have a guarantee that all cpu actually detect the related RSB underflow? It wouldn't surprise me if at least some cpu just let it wrap. This would means that userspace would see return predictions based on the values the kernel 'stuffed' into the RSB to fill it. Potentially this leaks a kernel address to userspace. David
Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
On Sun, 2018-01-14 at 16:05 -0800, Andi Kleen wrote:
> > + if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> > + !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> > + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > + pr_info("Filling RSB on context switch\n");
> > + }
>
> Missing an option to turn this off.
Deliberately so. You can already boot with 'spectre_v2=off' to turn off
the mitigations. We are not intending to permit all the bullshit micro-
management of IBRS=3/IBPB=2/RSB=π nonsense.
If you choose retpoline, you get the RSB stuffing which is appropriate
along with that. With IBRS, you get the RSB stuffing which is
appropriate with that. You don't get command line or sysfs tunables to
mess it. You *do* have the source code, if you really want to make
changes. Don't.
smime.p7s
Description: S/MIME cryptographic signature
Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
On Sun, Jan 14, 2018 at 04:05:54PM -0800, Andi Kleen wrote:
> > + if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> > +!boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> > + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > + pr_info("Filling RSB on context switch\n");
> > + }
>
> Missing an option to turn this off.
My earlier patch did this properly by folding it
into the big option parser.
https://marc.info/?l=linux-kernel&m=151578282016915&w=2
-Andi
Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
> + if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> + !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> + pr_info("Filling RSB on context switch\n");
> + }
Missing an option to turn this off.
-Andi
[tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
Commit-ID: c995efd5a740d9cbafbf58bde4973e8b50b4d761 Gitweb: https://git.kernel.org/tip/c995efd5a740d9cbafbf58bde4973e8b50b4d761 Author: David Woodhouse AuthorDate: Fri, 12 Jan 2018 17:49:25 + Committer: Thomas Gleixner CommitDate: Mon, 15 Jan 2018 00:32:44 +0100 x86/retpoline: Fill RSB on context switch for affected CPUs On context switch from a shallow call stack to a deeper one, as the CPU does 'ret' up the deeper side it may encounter RSB entries (predictions for where the 'ret' goes to) which were populated in userspace. This is problematic if neither SMEP nor KPTI (the latter of which marks userspace pages as NX for the kernel) are active, as malicious code in userspace may then be executed speculatively. Overwrite the CPU's return prediction stack with calls which are predicted to return to an infinite loop, to "capture" speculation if this happens. This is required both for retpoline, and also in conjunction with IBRS for !SMEP && !KPTI. On Skylake+ the problem is slightly different, and an *underflow* of the RSB may cause errant branch predictions to occur. So there it's not so much overwrite, as *filling* the RSB to attempt to prevent it getting empty. This is only a partial solution for Skylake+ since there are many other conditions which may result in the RSB becoming empty. The full solution on Skylake+ is to use IBRS, which will prevent the problem even when the RSB becomes empty. With IBRS, the RSB-stuffing will not be required on context switch. [ tglx: Added missing vendor check and slighty massaged comments and changelog ] Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Acked-by: Arjan van de Ven Cc: gno...@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: Andi Kleen Cc: Josh Poimboeuf Cc: thomas.lenda...@amd.com Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Tim Chen Cc: Greg Kroah-Hartman Cc: Paul Turner Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-d...@amazon.co.uk --- arch/x86/entry/entry_32.S | 11 +++ arch/x86/entry/entry_64.S | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 36 4 files changed, 59 insertions(+) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index a1f28a5..60c4c34 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -244,6 +244,17 @@ ENTRY(__switch_to_asm) movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset #endif +#ifdef CONFIG_RETPOLINE + /* +* When switching from a shallower to a deeper call stack +* the RSB may either underflow or use entries populated +* with userspace addresses. On CPUs where those concerns +* exist, overwrite the RSB with entries which capture +* speculative execution to prevent attack. +*/ + FILL_RETURN_BUFFER %ebx, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW +#endif + /* restore callee-saved registers */ popl%esi popl%edi diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 59874bc..d54a0ed 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -487,6 +487,17 @@ ENTRY(__switch_to_asm) movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset #endif +#ifdef CONFIG_RETPOLINE + /* +* When switching from a shallower to a deeper call stack +* the RSB may either underflow or use entries populated +* with userspace addresses. On CPUs where those concerns +* exist, overwrite the RSB with entries which capture +* speculative execution to prevent attack. +*/ + FILL_RETURN_BUFFER %r12, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW +#endif + /* restore callee-saved registers */ popq%r15 popq%r14 diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index f275447..aa09559 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -211,6 +211,7 @@ #define X86_FEATURE_AVX512_4FMAPS ( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */ #define X86_FEATURE_MBA( 7*32+18) /* Memory Bandwidth Allocation */ +#define X86_FEATURE_RSB_CTXSW ( 7*32+19) /* Fill RSB on context switches */ /* Virtualization flags: Linux defined, word 8 */ #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */ diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index e4dc261..390b3dc 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -23,6 +23,7 @@ #include #include #include +#include static void __init spectre_v2_select_mitigation(void); @@ -155,6 +156,23 @@ disable: return SPECTRE_V2_CMD_NONE; } +/* Check for Skylake-like CPUs (for RSB handling) */ +static
[tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs
Commit-ID: a0ab15c0fb68e202bebd9b17fa49fd7ec48975b3 Gitweb: https://git.kernel.org/tip/a0ab15c0fb68e202bebd9b17fa49fd7ec48975b3 Author: David Woodhouse AuthorDate: Fri, 12 Jan 2018 17:49:25 + Committer: Thomas Gleixner CommitDate: Sun, 14 Jan 2018 16:41:39 +0100 x86/retpoline: Fill RSB on context switch for affected CPUs On context switch from a shallow call stack to a deeper one, as the CPU does 'ret' up the deeper side it may encounter RSB entries (predictions for where the 'ret' goes to) which were populated in userspace. This is problematic if neither SMEP nor KPTI (the latter of which marks userspace pages as NX for the kernel) are active, as malicious code in userspace may then be executed speculatively. Overwrite the CPU's return prediction stack with calls which are predicted to return to an infinite loop, to "capture" speculation if this happens. This is required both for retpoline, and also in conjunction with IBRS for !SMEP && !KPTI. On Skylake+ the problem is slightly different, and an *underflow* of the RSB may cause errant branch predictions to occur. So there it's not so much overwrite, as *filling* the RSB to attempt to prevent it getting empty. This is only a partial solution for Skylake+ since there are many other conditions which may result in the RSB becoming empty. The full solution on Skylake+ is to use IBRS, which will prevent the problem even when the RSB becomes empty. With IBRS, the RSB-stuffing will not be required on context switch. [ tglx: Added missing vendor check and slighty massaged comments and changelog ] Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Acked-by: Arjan van de Ven Cc: gno...@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: Andi Kleen Cc: Josh Poimboeuf Cc: thomas.lenda...@amd.com Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Tim Chen Cc: Greg Kroah-Hartman Cc: Paul Turner Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-d...@amazon.co.uk --- arch/x86/entry/entry_32.S | 11 +++ arch/x86/entry/entry_64.S | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/bugs.c | 36 4 files changed, 59 insertions(+) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index a1f28a5..60c4c34 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -244,6 +244,17 @@ ENTRY(__switch_to_asm) movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset #endif +#ifdef CONFIG_RETPOLINE + /* +* When switching from a shallower to a deeper call stack +* the RSB may either underflow or use entries populated +* with userspace addresses. On CPUs where those concerns +* exist, overwrite the RSB with entries which capture +* speculative execution to prevent attack. +*/ + FILL_RETURN_BUFFER %ebx, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW +#endif + /* restore callee-saved registers */ popl%esi popl%edi diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 59874bc..d54a0ed 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -487,6 +487,17 @@ ENTRY(__switch_to_asm) movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset #endif +#ifdef CONFIG_RETPOLINE + /* +* When switching from a shallower to a deeper call stack +* the RSB may either underflow or use entries populated +* with userspace addresses. On CPUs where those concerns +* exist, overwrite the RSB with entries which capture +* speculative execution to prevent attack. +*/ + FILL_RETURN_BUFFER %r12, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW +#endif + /* restore callee-saved registers */ popq%r15 popq%r14 diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index f275447..aa09559 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -211,6 +211,7 @@ #define X86_FEATURE_AVX512_4FMAPS ( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */ #define X86_FEATURE_MBA( 7*32+18) /* Memory Bandwidth Allocation */ +#define X86_FEATURE_RSB_CTXSW ( 7*32+19) /* Fill RSB on context switches */ /* Virtualization flags: Linux defined, word 8 */ #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */ diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index e4dc261..390b3dc 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -23,6 +23,7 @@ #include #include #include +#include static void __init spectre_v2_select_mitigation(void); @@ -155,6 +156,23 @@ disable: return SPECTRE_V2_CMD_NONE; } +/* Check for Skylake-like CPUs (for RSB handling) */ +static
