Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Wed, 2018-01-24 at 18:40 +, Alan Cox wrote: > Nobody has published official statements on Cyrix or AMD 32bit processors > so we don't know if they are vulnerable to meltdown. One problem I > suspect is that as with things like Alpha 21264 - the people who knew are > probably long retired.

Re: [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

On Wed, 2018-01-24 at 18:29 +0100, Greg KH wrote: > > > + /* Dropped repeat of SKX 50654, 0x23c */ > > Nit, but why comment that you dropped a repeat?  No one cares, do they? > You already said above where this info came from. I started off by pedantically noted everywhere I'd had to

Re: [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

On Wed, 2018-01-24 at 18:29 +0100, Greg KH wrote: > > > + /* Dropped repeat of SKX 50654, 0x23c */ > > Nit, but why comment that you dropped a repeat?  No one cares, do they? > You already said above where this info came from. I started off by pedantically noted everywhere I'd had to

Re: [PATCH v3 3/6] x86/cpufeatures: Add AMD feature bits for Speculation Control

On Wed, 2018-01-24 at 18:20 +0100, Greg KH wrote: > On Wed, Jan 24, 2018 at 04:57:02PM +0000, David Woodhouse wrote: > > > > AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. > > See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...

Re: [PATCH v3 3/6] x86/cpufeatures: Add AMD feature bits for Speculation Control

On Wed, 2018-01-24 at 18:20 +0100, Greg KH wrote: > On Wed, Jan 24, 2018 at 04:57:02PM +0000, David Woodhouse wrote: > > > > AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. > > See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Wed, 2018-01-24 at 17:07 +, Alan Cox wrote: > > > >   > > +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = { > > + { X86_VENDOR_AMD }, > > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY }, > > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Wed, 2018-01-24 at 17:07 +, Alan Cox wrote: > > > >   > > +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = { > > + { X86_VENDOR_AMD }, > > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY }, > > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,

[PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not vulnerable. Roll the AMD exemption into the x86_match_cpu() table too. Based on suggestions from Dave Hansen and Alan Cox. Signed-off-by: David

[PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not vulnerable. Roll the AMD exemption into the x86_match_cpu() table too. Based on suggestions from Dave Hansen and Alan Cox. Signed-off-by: David

[PATCH v3 1/6] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Reviewed-by: Borislav Petkov <b..

[PATCH v3 1/6] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse Reviewed-by: Borislav Petkov --- arch/x86/include/asm

[PATCH v3 2/6] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse <dw...@infradead.org> Reviewed-by: Borislav Petkov <b...@suse.de> --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch

[PATCH v3 2/6] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse Reviewed-by: Borislav Petkov --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86

[PATCH v3 3/6] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...@amd.com Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v3 3/6] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39...@amd.com Signed-off-by: David Woodhouse --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm

[PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

s here too, because hypervisors *may* have been exposing those bits even on Intel chips, for fine-grained control of what's available. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kernel/cpu/intel.c | 76 + 1 file changed, 76 ins

[PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

s here too, because hypervisors *may* have been exposing those bits even on Intel chips, for fine-grained control of what's available. Signed-off-by: David Woodhouse --- arch/x86/kernel/cpu/intel.c | 76 + 1 file changed, 76 insertions(+) diff --git

[PATCH v3 0/6] Basic Speculation Control feature support

it might as well be part of this. Treat it as an RFC perhaps. v2: Cleanups, add AMD bits for STIBP/SPEC_CTRL. v3: Add more CPUs to the exemption for KPTI and clean that up. Add microcode blacklist (RFC) David Woodhouse (6): x86/cpufeatures: Add CPUID_7_EDX CPUID leaf x86/cpufeatures: Add Intel

[PATCH v3 0/6] Basic Speculation Control feature support

it might as well be part of this. Treat it as an RFC perhaps. v2: Cleanups, add AMD bits for STIBP/SPEC_CTRL. v3: Add more CPUs to the exemption for KPTI and clean that up. Add microcode blacklist (RFC) David Woodhouse (6): x86/cpufeatures: Add CPUID_7_EDX CPUID leaf x86/cpufeatures: Add Intel

[PATCH v3 4/6] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/msr-index.h | 12 1 file changed, 12 insertions(+)

[PATCH v3 4/6] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse --- arch/x86/include/asm/msr-index.h | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 + > David Woodhouse <d...@amazon.co.uk> wrote: > > > > > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO > > bit set, they don't need KPTI either

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 + > David Woodhouse wrote: > > > > > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO > > bit set, they don't need KPTI either. > This is st

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 07:09 -0800, Arjan van de Ven wrote: > On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote: > > Arjan, why do you think this can only be done as a whitelist? > > I suggested a minimum version list for those cpus that need it. > > microcode versions are tricky (and we've released

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 07:09 -0800, Arjan van de Ven wrote: > On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote: > > Arjan, why do you think this can only be done as a whitelist? > > I suggested a minimum version list for those cpus that need it. > > microcode versions are tricky (and we've released

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 13:29 +0100, Peter Zijlstra wrote: > > Yes :/ > > We could look at extending x86_cpu_id and x86_match_cpu with a stepping > option I suppose, but that might be lots of churn. That goes all the way to mod_deviceinfo, and would be horrid. We could add an

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 13:29 +0100, Peter Zijlstra wrote: > > Yes :/ > > We could look at extending x86_cpu_id and x86_match_cpu with a stepping > option I suppose, but that might be lots of churn. That goes all the way to mod_deviceinfo, and would be horrid. We could add an

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 08:49 -0200, Henrique de Moraes Holschuh wrote: > On Wed, 24 Jan 2018, David Woodhouse wrote: > > > > I'm kind of tempted to turn it into a whitelist just by adding 1 to the > > microcode revision in each table entry. Sure, that N+1 might be anothe

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 08:49 -0200, Henrique de Moraes Holschuh wrote: > On Wed, 24 Jan 2018, David Woodhouse wrote: > > > > I'm kind of tempted to turn it into a whitelist just by adding 1 to the > > microcode revision in each table entry. Sure, that N+1 might be anothe

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote: > > Typically tglx likes to use x86_match_cpu() for these things; see also > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to > errata"). Ewww. static u32 hsx_deadline_rev(void) {        switch (boot_cpu_data.x86_mask) {    

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote: > > Typically tglx likes to use x86_match_cpu() for these things; see also > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to > errata"). Ewww. static u32 hsx_deadline_rev(void) {        switch (boot_cpu_data.x86_mask) {    

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote: > On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > > > > The BPF interpreter has been used as part of the spectre 2 attack > > CVE-2017-5715. > > > > A quote from goolge project zero blog: > > "At this point, it would normally be

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote: > On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > > > > The BPF interpreter has been used as part of the spectre 2 attack > > CVE-2017-5715. > > > > A quote from goolge project zero blog: > > "At this point, it would normally be

Re: Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control]

On Wed, 2018-01-24 at 09:37 +0100, Dominik Brodowski wrote: > On Wed, Jan 24, 2018 at 07:29:53AM +0100, Martin Schwidefsky wrote: > > > > On Tue, 23 Jan 2018 18:07:19 +0100 > > Dominik Brodowski wrote: > > > > > > > > On Tue, Jan 23, 2018 at 02:07:01PM +0100, Martin

Re: Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control]

On Wed, 2018-01-24 at 09:37 +0100, Dominik Brodowski wrote: > On Wed, Jan 24, 2018 at 07:29:53AM +0100, Martin Schwidefsky wrote: > > > > On Tue, 23 Jan 2018 18:07:19 +0100 > > Dominik Brodowski wrote: > > > > > > > > On Tue, Jan 23, 2018 at 02:07:01PM +0100, Martin Schwidefsky wrote: > > > >

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote: > Typically tglx likes to use x86_match_cpu() for these things; see also > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to > errata"). Thanks, will fix. I think we might also end up in whitelist mode, adding "known good"

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote: > Typically tglx likes to use x86_match_cpu() for these things; see also > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to > errata"). Thanks, will fix. I think we might also end up in whitelist mode, adding "known good"

Re: [PATCH v2 3/5] x86/cpufeatures: Add AMD feature bits for Speculation Control

On Wed, 2018-01-24 at 11:39 +0300, Kirill A. Shutemov wrote: > On Tue, Jan 23, 2018 at 04:52:53PM +0000, David Woodhouse wrote: > > > > AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. > > Documented at https://lkml.org/lkml/2018/1/21/112 > >

Re: [PATCH v2 3/5] x86/cpufeatures: Add AMD feature bits for Speculation Control

On Wed, 2018-01-24 at 11:39 +0300, Kirill A. Shutemov wrote: > On Tue, Jan 23, 2018 at 04:52:53PM +0000, David Woodhouse wrote: > > > > AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. > > Documented at https://lkml.org/lkml/2018/1/21/112 > >

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 10:40 -0800, Dave Hansen wrote: > > I'd really rather we break this out into a nice, linear set of > true/false conditions. > > bool early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c) > { > u64 ia32_cap = 0; > > /* AMD processors are not subject to

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 10:40 -0800, Dave Hansen wrote: > > I'd really rather we break this out into a nice, linear set of > true/false conditions. > > bool early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c) > { > u64 ia32_cap = 0; > > /* AMD processors are not subject to

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 17:00 -0800, Andy Lutomirski wrote: > On Tue, Jan 23, 2018 at 4:47 PM, Tim Chen wrote: > > > > On 01/23/2018 03:14 PM, Woodhouse, David wrote: > > > > > > On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: > > > > > > > > > > > > > > Not

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 10:12 -0800, Andi Kleen wrote: > > - if (c->x86_vendor != X86_VENDOR_AMD) > > - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN); > > + if (c->x86_vendor != X86_VENDOR_AMD) { > > + u64 ia32_cap = 0; > > + > > + if (cpu_has(c,

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On Tue, 2018-01-23 at 10:12 -0800, Andi Kleen wrote: > > - if (c->x86_vendor != X86_VENDOR_AMD) > > - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN); > > + if (c->x86_vendor != X86_VENDOR_AMD) { > > + u64 ia32_cap = 0; > > + > > + if (cpu_has(c,

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 17:00 -0800, Andy Lutomirski wrote: > On Tue, Jan 23, 2018 at 4:47 PM, Tim Chen wrote: > > > > On 01/23/2018 03:14 PM, Woodhouse, David wrote: > > > > > > On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: > > > > > > > > > > > > > > Not sure.  Maybe to start, the

Re: [PATCH v8 04/12] x86/spectre: Add boot time option to select Spectre v2 mitigation

On Tue, 2018-01-23 at 23:40 +0100, Borislav Petkov wrote: > > Btw, this came up today: do we have an idea how to detect objects built > with gcc which has retpoline support? > > The only way I could think of is boot the respective kernel and stare at > dmesg: > > [    0.064006] Spectre V2

Re: [PATCH v8 04/12] x86/spectre: Add boot time option to select Spectre v2 mitigation

On Tue, 2018-01-23 at 23:40 +0100, Borislav Petkov wrote: > > Btw, this came up today: do we have an idea how to detect objects built > with gcc which has retpoline support? > > The only way I could think of is boot the respective kernel and stare at > dmesg: > > [    0.064006] Spectre V2

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Sun, 2018-01-21 at 15:31 +0100, Thomas Gleixner wrote: > >  > > XX: Do we want a microcode blacklist? > > Oh yes, we want a microcode blacklist. Ideally we refuse to load the > affected microcode in the first place and if its already loaded then at > least avoid to use the borked features. >

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On Sun, 2018-01-21 at 15:31 +0100, Thomas Gleixner wrote: > >  > > XX: Do we want a microcode blacklist? > > Oh yes, we want a microcode blacklist. Ideally we refuse to load the > affected microcode in the first place and if its already loaded then at > least avoid to use the borked features. >

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

> On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote: > > static __initdata struct x86_cpu_id cpu_in_order[] = { >     { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY }, >     { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY }, >     {

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

> On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote: > > static __initdata struct x86_cpu_id cpu_in_order[] = { >     { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY }, >     { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY }, >     {

Re: [PATCH 06/24] x86,kvm: Fix indirect calls in emulator

On Tue, 2018-01-23 at 21:28 +0100, Borislav Petkov wrote: > > >   flags = (flags & EFLAGS_MASK) | X86_EFLAGS_IF; > > - asm("push %[flags]; popf; call *%[fastop]" > > - : "=a"(rc) : [fastop]"r"(fop), [flags]"r"(flags)); > > + asm("push %[flags]; popf; " CALL_NOSPEC > > +

Re: [PATCH 06/24] x86,kvm: Fix indirect calls in emulator

On Tue, 2018-01-23 at 21:28 +0100, Borislav Petkov wrote: > > >   flags = (flags & EFLAGS_MASK) | X86_EFLAGS_IF; > > - asm("push %[flags]; popf; call *%[fastop]" > > - : "=a"(rc) : [fastop]"r"(fop), [flags]"r"(flags)); > > + asm("push %[flags]; popf; " CALL_NOSPEC > > +

[PATCH v2 4/5] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/msr-index.h | 12 1 file changed, 12 insertions(+)

[PATCH v2 4/5] x86/msr: Add definitions for new speculation control MSRs

Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by: David Woodhouse --- arch/x86/include/asm/msr-index.h | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86

[PATCH v2 1/5] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Reviewed-by: Borislav Petkov <b..

[PATCH v2 1/5] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf

This is a pure feature bits leaf. We have two AVX512 feature bits in it already which were handled as scattered bits, and I'm about to add three more from this leaf for speculation control features. Signed-off-by: David Woodhouse Reviewed-by: Borislav Petkov --- arch/x86/include/asm

[PATCH v2 3/5] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. Documented at https://lkml.org/lkml/2018/1/21/112 Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/inclu

[PATCH v2 3/5] x86/cpufeatures: Add AMD feature bits for Speculation Control

AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. Documented at https://lkml.org/lkml/2018/1/21/112 Signed-off-by: David Woodhouse --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86

[PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, they don't need KPTI either. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kernel/cpu/common.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/kern

[PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, they don't need KPTI either. Signed-off-by: David Woodhouse --- arch/x86/kernel/cpu/common.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86

[PATCH v2 2/5] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse <dw...@infradead.org> Reviewed-by: Borislav Petkov <b...@suse.de> --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch

[PATCH v2 0/5] Basic Speculation Control feature support

Baby steps... this is just the basic CPUID and MSR definitions for AMD and Intel, followedby the complete no-brainer: Disable KPTI on Intel CPUs which set the RDCL_NO bit to say that they don't need it. David Woodhouse (5): x86/cpufeatures: Add CPUID_7_EDX CPUID leaf x86/cpufeatures: Add

[PATCH v2 0/5] Basic Speculation Control feature support

Baby steps... this is just the basic CPUID and MSR definitions for AMD and Intel, followedby the complete no-brainer: Disable KPTI on Intel CPUs which set the RDCL_NO bit to say that they don't need it. David Woodhouse (5): x86/cpufeatures: Add CPUID_7_EDX CPUID leaf x86/cpufeatures: Add

[PATCH v2 2/5] x86/cpufeatures: Add Intel feature bits for Speculation Control

Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by: David Woodhouse Reviewed-by: Borislav Petkov --- arch/x86/include/asm/cpufeatures.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86

Re: [PATCH 00/24] objtool: retpoline and asm-goto validation

On Tue, 2018-01-23 at 16:42 +0100, Peter Zijlstra wrote: > drivers/watchdog/.tmp_hpwdt.o: warning: objtool: .text+0x24: indirect call > found in RETPOLINE build You're calling into BIOS there. Not a lot of point in protecting that one. This is one of the cases where we were saying you needed to

Re: [PATCH 00/24] objtool: retpoline and asm-goto validation

On Tue, 2018-01-23 at 16:42 +0100, Peter Zijlstra wrote: > drivers/watchdog/.tmp_hpwdt.o: warning: objtool: .text+0x24: indirect call > found in RETPOLINE build You're calling into BIOS there. Not a lot of point in protecting that one. This is one of the cases where we were saying you needed to

[PATCH] x86/cpuid: Fewer CPUID invocations in init_scattered_cpuid_features()

We were doing a fresh CPUID for every single bit in every single output register. Do it once and then harvest *all* the bits we want. We were also doing the max_level check with a new CPUID invocation for every single bit. Stop that too. Signed-off-by: David Woodhouse <d...@amazon.co

[PATCH] x86/cpuid: Fewer CPUID invocations in init_scattered_cpuid_features()

We were doing a fresh CPUID for every single bit in every single output register. Do it once and then harvest *all* the bits we want. We were also doing the max_level check with a new CPUID invocation for every single bit. Stop that too. Signed-off-by: David Woodhouse --- Spotted this in my

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:44 +0100, Ingo Molnar wrote: > * David Woodhouse <dw...@infradead.org> wrote: > > Hm? We still have GCC emitting 'call __fentry__' don't we? Would be nice to > > get  > > to the point where we can patch *that* out into a NOP... or are you sayi

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:44 +0100, Ingo Molnar wrote: > * David Woodhouse wrote: > > Hm? We still have GCC emitting 'call __fentry__' don't we? Would be nice to > > get  > > to the point where we can patch *that* out into a NOP... or are you saying > > we  > > a

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:23 +0100, Ingo Molnar wrote: > * David Woodhouse <dw...@infradead.org> wrote: > > > > > > > > > On SkyLake this would add an overhead of maybe 2-3 cycles per function > > > call and  > > > obviously

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:23 +0100, Ingo Molnar wrote: > * David Woodhouse wrote: > > > > > > > > > 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

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:15 +0100, Ingo Molnar wrote: > > BTW., the reason this is enabled on all distro kernels is because the > overhead is  > a single patched-in NOP instruction in the function epilogue, when tracing is  > disabled. So it's not even a CALL+RET - it's a patched in NOP. Hm? We

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 11:15 +0100, Ingo Molnar wrote: > > BTW., the reason this is enabled on all distro kernels is because the > overhead is  > a single patched-in NOP instruction in the function epilogue, when tracing is  > disabled. So it's not even a CALL+RET - it's a patched in NOP. Hm? We

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 10:27 +0100, Ingo Molnar wrote: > * Ingo Molnar wrote: > > > > > 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

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 10:27 +0100, Ingo Molnar wrote: > * Ingo Molnar wrote: > > > > > 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

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 08:53 +0100, Ingo Molnar wrote: > > 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: > >   81a01a40 <__fentry__>: >   81a01a40:   c3   

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Tue, 2018-01-23 at 08:53 +0100, Ingo Molnar wrote: > > 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: > >   81a01a40 <__fentry__>: >   81a01a40:   c3   

Re: [PATCH] x86/retpoline: Remove the esp/rsp thunk

l is emitted incorrectly. > > Fixes: 76b043848fd2 ("x86/retpoline: Add initial retpoline support") > Suggested-by: Jeff Law <l...@redhat.com> > Signed-off-by: Waiman Long <long...@redhat.com> Acked-by: David Woodhouse <d...@amazon.co.uk> I spotted that and *almos

Re: [PATCH] x86/retpoline: Remove the esp/rsp thunk

l is emitted incorrectly. > > Fixes: 76b043848fd2 ("x86/retpoline: Add initial retpoline support") > Suggested-by: Jeff Law > Signed-off-by: Waiman Long Acked-by: David Woodhouse I spotted that and *almost* removed it a couple of times in other refactoring, but after abandoning

Re: [RFC 00/10] Speculation Control feature support

On Sun, 2018-01-21 at 09:02 -0500, Konrad Rzeszutek Wilk wrote: > > > Depend on what we expose to the guest. That is if the guest is not suppose to > have this exposed > (say cpuid 27 bit is not exposed) then trap on the MSR (and give an #GP)? I think for SPEC_CTRL we want to trap on the MSR

Re: [RFC 00/10] Speculation Control feature support

On Sun, 2018-01-21 at 09:02 -0500, Konrad Rzeszutek Wilk wrote: > > > Depend on what we expose to the guest. That is if the guest is not suppose to > have this exposed > (say cpuid 27 bit is not exposed) then trap on the MSR (and give an #GP)? I think for SPEC_CTRL we want to trap on the MSR

Re: [v8,02/12] objtool: Allow alternatives to be ignored

On Mon, 2018-01-22 at 12:25 -0800, Guenter Roeck wrote: > > It uses "-mindirect-branch=thunk -mindirect-branch-loop=pause > -fno-jump-tables", though I don't know if that even exists in > upstream gcc (it is the gcc use for Chrome OS builds). I'll pass > your feedback to our compiler team. We

Re: [v8,02/12] objtool: Allow alternatives to be ignored

On Mon, 2018-01-22 at 12:25 -0800, Guenter Roeck wrote: > > It uses "-mindirect-branch=thunk -mindirect-branch-loop=pause > -fno-jump-tables", though I don't know if that even exists in > upstream gcc (it is the gcc use for Chrome OS builds). I'll pass > your feedback to our compiler team. We

Re: [v8,02/12] objtool: Allow alternatives to be ignored

On Thu, 2018-01-18 at 11:41 -0800, Guenter Roeck wrote: > > > Not sure, does your gcc have retpolines?  Give me your .o file and I can > > diagnose it. > >  > Yes, it does, only it is the gcc from the Google toolchain which may > generate different code than the upstream version. > > I attached

Re: [v8,02/12] objtool: Allow alternatives to be ignored

On Thu, 2018-01-18 at 11:41 -0800, Guenter Roeck wrote: > > > Not sure, does your gcc have retpolines?  Give me your .o file and I can > > diagnose it. > >  > Yes, it does, only it is the gcc from the Google toolchain which may > generate different code than the upstream version. > > I attached

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 14:27 -0800, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 2:00 PM, David Woodhouse <dw...@infradead.org> wrote: > >> > >> The patches do things like add the garbage MSR writes to the kernel > >> entry/exit points. That's insane

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 14:27 -0800, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 2:00 PM, David Woodhouse wrote: > >> > >> The patches do things like add the garbage MSR writes to the kernel > >> entry/exit points. That's insane. That says "we're trying to pr

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On Mon, 2018-01-22 at 11:19 +0100, Peter Zijlstra wrote: > Right, so if its v2/retpoline only, we really should do this asap and > then rebuild world on distros (or arch/gentoo people could read a book > or something). By the time we manage to rebuild all the distros, I *seriously* hope that

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On Mon, 2018-01-22 at 11:19 +0100, Peter Zijlstra wrote: > Right, so if its v2/retpoline only, we really should do this asap and > then rebuild world on distros (or arch/gentoo people could read a book > or something). By the time we manage to rebuild all the distros, I *seriously* hope that

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 13:35 -0800, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse wrote: > > As a hack for existing CPUs, it's just about tolerable — as long as it > > can die entirely by the next generation. > > That's part of the big problem

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 13:35 -0800, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse wrote: > > As a hack for existing CPUs, it's just about tolerable — as long as it > > can die entirely by the next generation. > > That's part of the big problem

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 20:19 +, Andrew Cooper wrote: > On 21/01/2018 20:04, David Woodhouse wrote: > > For the specific case of IBPB, knowing what we do about non- > > architectural behaviour, that's probably true. > > This IBPB case is an attacker trying to attack a n

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 20:19 +, Andrew Cooper wrote: > On 21/01/2018 20:04, David Woodhouse wrote: > > For the specific case of IBPB, knowing what we do about non- > > architectural behaviour, that's probably true. > > This IBPB case is an attacker trying to attack a n

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: > All of this is pure garbage. > > Is Intel really planning on making this shit architectural? Has > anybody talked to them and told them they are f*cking insane? > > Please, any Intel engineers here - talk to your managers.  If the

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: > All of this is pure garbage. > > Is Intel really planning on making this shit architectural? Has > anybody talked to them and told them they are f*cking insane? > > Please, any Intel engineers here - talk to your managers.  If the

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 20:54 +0100, Borislav Petkov wrote: > On Sun, Jan 21, 2018 at 07:31:39PM +0000, David Woodhouse wrote: > > > if (boot_cpu_has(X86_FEATURE_IBPB)) > > > wrmsr(MSR_IA32_PRED_CMD, PRED_CMD_IBPB, 0); > > >  > > >

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 20:54 +0100, Borislav Petkov wrote: > On Sun, Jan 21, 2018 at 07:31:39PM +0000, David Woodhouse wrote: > > > if (boot_cpu_has(X86_FEATURE_IBPB)) > > > wrmsr(MSR_IA32_PRED_CMD, PRED_CMD_IBPB, 0); > > >  > > >

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On Sun, 2018-01-21 at 19:37 +, Andrew Cooper wrote: > > It doesn't matter if an attacker can use SP1 to try and skip the IBPB. > > Exits to userspace/guest are serialising (with some retroactive updates > to the architecture spec coming), so an attacker can't cause victim code > to be

<    5   6   7   8   9   10   11   12   13   14   >