[tip:x86/pti] x86/speculation: Correct Speculation Control microcode blacklist again

Commit-ID: d37fc6d360a404b208547ba112e7dabb6533c7fc Gitweb: https://git.kernel.org/tip/d37fc6d360a404b208547ba112e7dabb6533c7fc Author: David Woodhouse AuthorDate: Mon, 12 Feb 2018 15:27:34 + Committer: Ingo Molnar CommitDate: Tue, 13 Feb 2018 08:58:59 +0100 x86/speculation

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 09:02 +0100, Paolo Bonzini wrote: > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -3419,13 +3419,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, > > struct msr_data *msr_info) > >   > >   vmx->spec_ctrl = data; > >   > > - if

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 09:02 +0100, Paolo Bonzini wrote: > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -3419,13 +3419,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, > > struct msr_data *msr_info) > >   > >   vmx->spec_ctrl = data; > >   > > - if

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 08:47 +0100, Ingo Molnar wrote: > * David Woodhouse <d...@amazon.co.uk> wrote: > > > > > +extern enum spectre_v2_mitigation spectre_v2_enabled; > > This needs to be exported if the KVM module wants to use it. > > > > >

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 08:47 +0100, Ingo Molnar wrote: > * David Woodhouse wrote: > > > > > +extern enum spectre_v2_mitigation spectre_v2_enabled; > > This needs to be exported if the KVM module wants to use it. > > > > > +static inline bool spectre_

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Mon, 2018-02-12 at 09:33 -0800, Kees Cook wrote: > On Mon, Feb 12, 2018 at 9:05 AM, Peter Zijlstra wrote: > > On Mon, Feb 12, 2018 at 08:56:31AM -0800, Kees Cook wrote: > >> That would be bad: Android exclusively builds with clang. > > > > So implement asm-goto already,

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Mon, 2018-02-12 at 09:33 -0800, Kees Cook wrote: > On Mon, Feb 12, 2018 at 9:05 AM, Peter Zijlstra wrote: > > On Mon, Feb 12, 2018 at 08:56:31AM -0800, Kees Cook wrote: > >> That would be bad: Android exclusively builds with clang. > > > > So implement asm-goto already, and do asm-cc-output

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

On Mon, 2018-02-12 at 11:29 +0530, afzal mohammed wrote: > Hi, > > On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote: > > > > > x86/speculation: Use IBRS if available before calling into firmware > > > > Retpoline means the kerne

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

On Mon, 2018-02-12 at 11:29 +0530, afzal mohammed wrote: > Hi, > > On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote: > > > > > x86/speculation: Use IBRS if available before calling into firmware > > > > Retpoline means the kerne

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Mon, 2018-02-12 at 09:26 +0100, Peter Zijlstra wrote: > On Sun, Feb 11, 2018 at 10:13:44AM -0800, Linus Torvalds wrote: > > > That actually sounds like we could just > >  > >  (a) make gcc 4.5 be the minimum required version > >  > >  (b) actually error out if we find a bad compiler > > So

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Mon, 2018-02-12 at 09:26 +0100, Peter Zijlstra wrote: > On Sun, Feb 11, 2018 at 10:13:44AM -0800, Linus Torvalds wrote: > > > That actually sounds like we could just > >  > >  (a) make gcc 4.5 be the minimum required version > >  > >  (b) actually error out if we find a bad compiler > > So

Re: [PATCH] x86/speculation: Clean up various Spectre related details

On Sun, 2018-02-11 at 20:43 +0100, Ingo Molnar wrote: > > And should these say 'Spectre v2' not just 'Spectre'? > > Yeah, you are probably right, but I didn't want to make the messages too > specific  > - do we really know that this is the end of Spectre-style speculation holes? Well... if a

Re: [PATCH] x86/speculation: Clean up various Spectre related details

On Sun, 2018-02-11 at 20:43 +0100, Ingo Molnar wrote: > > And should these say 'Spectre v2' not just 'Spectre'? > > Yeah, you are probably right, but I didn't want to make the messages too > specific  > - do we really know that this is the end of Spectre-style speculation holes? Well... if a

[PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Acked-by: Arjan van de Ven <arjan.van.de@intel.com> --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 16

[PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse Acked-by: Arjan van de Ven --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 16 ++-- arch/x86/kvm/vmx.c | 17 ++

[PATCH 1/2] x86/speculation: Correct Speculation Control microcode blacklist again

expected to be a thing which keeps happening. Requested-by: Arjan van de Ven <arjan.van.de@intel.com> Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kernel/cpu/intel.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/in

[PATCH 1/2] x86/speculation: Correct Speculation Control microcode blacklist again

expected to be a thing which keeps happening. Requested-by: Arjan van de Ven Signed-off-by: David Woodhouse --- arch/x86/kernel/cpu/intel.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index f73b814..ef796f1

Re: [PATCH v2 1/6] x86/speculation: Update Speculation Control microcode blacklist

On Sat, 2018-02-10 at 23:39 +, David Woodhouse wrote: > > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -123,8 +123,6 @@ static const struct sku_microcode > spectre_bad_microcodes[] = { > { INTEL_FAM6_KABYLAKE_MOBI

Re: [PATCH v2 1/6] x86/speculation: Update Speculation Control microcode blacklist

On Sat, 2018-02-10 at 23:39 +, David Woodhouse wrote: > > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -123,8 +123,6 @@ static const struct sku_microcode > spectre_bad_microcodes[] = { > { INTEL_FAM6_KABYLAKE_MOBI

Re: [PATCH v2 3/8] objtool: Add module specific retpoline rules

gt; Acked-by: Josh Poimboeuf <jpoim...@redhat.com> > Requested-by: David Woodhouse <dw...@infradead.org> > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> Acked-by: David Woodhouse <d...@amazon.co.uk> smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v2 3/8] objtool: Add module specific retpoline rules

gt; Acked-by: Josh Poimboeuf > Requested-by: David Woodhouse > Signed-off-by: Peter Zijlstra (Intel) Acked-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v2 4/8] objtool: Retpoline validation tweaks

On Mon, 2018-02-12 at 13:48 +0100, Peter Zijlstra wrote: > --- a/Makefile > +++ b/Makefile > @@ -486,6 +486,11 @@ KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG >  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  endif >   > +ifneq ($(call cc-option,-mindirect-branch=thunk-extern >

Re: [PATCH v2 4/8] objtool: Retpoline validation tweaks

On Mon, 2018-02-12 at 13:48 +0100, Peter Zijlstra wrote: > --- a/Makefile > +++ b/Makefile > @@ -486,6 +486,11 @@ KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG >  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  endif >   > +ifneq ($(call cc-option,-mindirect-branch=thunk-extern >

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote: > On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote: > > > +static inline void firmware_restrict_branch_speculation_start(void) > > > +{ > > > +   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS, > > > +

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote: > On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote: > > > +static inline void firmware_restrict_branch_speculation_start(void) > > > +{ > > > +   alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS, > > > +

Re: update spectre v2 microcodes blacklist

On Sat, 2018-02-10 at 20:14 +0300, Alexander Sergeyev wrote: > > > > I didn't fully match the updated revision guidance and > > spectre_bad_microcodes > I compared these lists and it seems that the only difference is about > skylakes.  > Everything else is covered by less-or-equal criteria on

Re: update spectre v2 microcodes blacklist

On Sat, 2018-02-10 at 20:14 +0300, Alexander Sergeyev wrote: > > > > I didn't fully match the updated revision guidance and > > spectre_bad_microcodes > I compared these lists and it seems that the only difference is about > skylakes.  > Everything else is covered by less-or-equal criteria on

[tip:x86/pti] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

Commit-ID: 930ce1a7a55bc0eb8917f453ee22f1b6d67df5cd Gitweb: https://git.kernel.org/tip/930ce1a7a55bc0eb8917f453ee22f1b6d67df5cd Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sat, 10 Feb 2018 23:39:23 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun,

[tip:x86/pti] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

Commit-ID: 930ce1a7a55bc0eb8917f453ee22f1b6d67df5cd Gitweb: https://git.kernel.org/tip/930ce1a7a55bc0eb8917f453ee22f1b6d67df5cd Author: David Woodhouse AuthorDate: Sat, 10 Feb 2018 23:39:23 + Committer: Ingo Molnar CommitDate: Sun, 11 Feb 2018 11:24:15 +0100 Revert &quo

[tip:x86/pti] KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods

Commit-ID: 33f1e899478efb7c77b2b833e7edee1203a24a48 Gitweb: https://git.kernel.org/tip/33f1e899478efb7c77b2b833e7edee1203a24a48 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sat, 10 Feb 2018 23:39:24 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun,

[tip:x86/pti] KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods

Commit-ID: 33f1e899478efb7c77b2b833e7edee1203a24a48 Gitweb: https://git.kernel.org/tip/33f1e899478efb7c77b2b833e7edee1203a24a48 Author: David Woodhouse AuthorDate: Sat, 10 Feb 2018 23:39:24 + Committer: Ingo Molnar CommitDate: Sun, 11 Feb 2018 11:24:15 +0100 KVM/x86: Reduce

[tip:x86/pti] x86/speculation: Update Speculation Control microcode blacklist

Commit-ID: 1751342095f0d2b36fa8114d8e12c5688c455ac4 Gitweb: https://git.kernel.org/tip/1751342095f0d2b36fa8114d8e12c5688c455ac4 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sat, 10 Feb 2018 23:39:22 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun,

[tip:x86/pti] x86/speculation: Update Speculation Control microcode blacklist

Commit-ID: 1751342095f0d2b36fa8114d8e12c5688c455ac4 Gitweb: https://git.kernel.org/tip/1751342095f0d2b36fa8114d8e12c5688c455ac4 Author: David Woodhouse AuthorDate: Sat, 10 Feb 2018 23:39:22 + Committer: Ingo Molnar CommitDate: Sun, 11 Feb 2018 11:24:15 +0100 x86/speculation

[tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Commit-ID: 670c3e8da87fa4046a55077b1409cf250865a203 Gitweb: https://git.kernel.org/tip/670c3e8da87fa4046a55077b1409cf250865a203 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sun, 11 Feb 2018 15:19:19 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun,

[tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Commit-ID: 670c3e8da87fa4046a55077b1409cf250865a203 Gitweb: https://git.kernel.org/tip/670c3e8da87fa4046a55077b1409cf250865a203 Author: David Woodhouse AuthorDate: Sun, 11 Feb 2018 15:19:19 + Committer: Ingo Molnar CommitDate: Sun, 11 Feb 2018 19:44:46 +0100 x86/speculation: Use

Re: [PATCH] x86/speculation: Clean up various Spectre related details

- s/KPTI/PTI > >  - remove various line-breaks that made the code uglier > > Cc: Andy Lutomirski <l...@kernel.org> > Cc: Arjan van de Ven <ar...@linux.intel.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Dan Williams <dan.j.willi...@intel.com> > Cc: Da

Re: [PATCH] x86/speculation: Clean up various Spectre related details

ove various line-breaks that made the code uglier > > Cc: Andy Lutomirski > Cc: Arjan van de Ven > Cc: Borislav Petkov > Cc: Dan Williams > Cc: Dave Hansen > Cc: David Woodhouse > Cc: David Woodhouse > Cc: Greg Kroah-Hartman > Cc: Josh Poimboeuf > Cc:

[PATCH v2.1] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- Helps to include the right header file. arch/x86/include/asm/apm.h | 6 ++ ar

[PATCH v2.1] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse --- Helps to include the right header file. arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm

[PATCH v2 2/6] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

registers. But no. Just no. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/nospec-branch.h | 13 + arch/x86/include/asm/processor.h | 3 --- arch/x86/kernel/cpu/bugs.c | 6 -- 3 files changed, 9 insertions(+), 13 deletions(-) diff

[PATCH v2 2/6] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

registers. But no. Just no. Signed-off-by: David Woodhouse --- arch/x86/include/asm/nospec-branch.h | 13 + arch/x86/include/asm/processor.h | 3 --- arch/x86/kernel/cpu/bugs.c | 6 -- 3 files changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/x86/include

[PATCH v2 0/6] Spectre v2 updates

the microcode blacklist to reflect the latest information from Intel. v2: Drop IBRS_ALL patch for the time being Add KVM MSR fixes (karahmed) Update microcode blacklist David Woodhouse (4): x86/speculation: Update Speculation Control microcode blacklist Revert "x86/speculation: Sim

[PATCH v2 1/6] x86/speculation: Update Speculation Control microcode blacklist

as OK. We still list 0x84 for the various Kaby Lake / Coffee Lake parts, as that appeared in one version of the blacklist and then reverted to 0x80 again. We can change it if 0x84 is actually announced to be safe. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kernel/cpu/i

[PATCH v2 0/6] Spectre v2 updates

the microcode blacklist to reflect the latest information from Intel. v2: Drop IBRS_ALL patch for the time being Add KVM MSR fixes (karahmed) Update microcode blacklist David Woodhouse (4): x86/speculation: Update Speculation Control microcode blacklist Revert "x86/speculation: Sim

[PATCH v2 1/6] x86/speculation: Update Speculation Control microcode blacklist

as OK. We still list 0x84 for the various Kaby Lake / Coffee Lake parts, as that appeared in one version of the blacklist and then reverted to 0x80 again. We can change it if 0x84 is actually announced to be safe. Signed-off-by: David Woodhouse --- arch/x86/kernel/cpu/intel.c | 4 1 file

[PATCH v2 4/6] X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs

result of msr_write_intercepted_l01 to implement the correct semantics. Fixes: 086e7d4118cc ("KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL") Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Reviewed-by: Jim Mattson <jmatt...@googl

[PATCH v2 4/6] X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs

the correct semantics. Fixes: 086e7d4118cc ("KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL") Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse Reviewed-by: Jim Mattson Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- ar

[PATCH v2 6/6] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 +

[PATCH v2 6/6] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm

[PATCH v2 5/6] KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap

KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: k...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- arch/x86/kvm/vmx.c | 3 ++- 1 file changed, 2

[PATCH v2 5/6] KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap

t;KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL") this was probably OK since the decision was always identical. This is no longer the case now since the MSR bitmap might actually change once we decide to not intercept SPEC_CTRL and PRED_CMD. Signed-off-by: KarimAllah Ahmed Signed-off

[PATCH v2 3/6] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

-by: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Reviewed-by: Filippo Sironi <sir...@amazon.de> Tested-by: Filippo Sironi <sir...@amazon.de> --- arch/x86/kvm/mmu.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-

[PATCH v2 3/6] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

-by: Linus Torvalds Signed-off-by: David Woodhouse Reviewed-by: Filippo Sironi Tested-by: Filippo Sironi --- arch/x86/kvm/mmu.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 2b8eb4d..cc83bdc 100644 --- a/arch/x86/kvm/m

Re: [PATCH 1/3] X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs

On Fri, 2018-02-09 at 15:15 -0800, Jim Mattson wrote: > On Thu, Feb 8, 2018 at 2:53 PM, KarimAllah Ahmed wrote: > > > > These two variables should check whether SPEC_CTRL and PRED_CMD are > > supposed to be passed through to L2 guests or not. While > >

Re: [PATCH 1/3] X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs

On Fri, 2018-02-09 at 15:15 -0800, Jim Mattson wrote: > On Thu, Feb 8, 2018 at 2:53 PM, KarimAllah Ahmed wrote: > > > > These two variables should check whether SPEC_CTRL and PRED_CMD are > > supposed to be passed through to L2 guests or not. While > > msr_write_intercepted_l01 would return

[RFC HACK] Make clang hate percpu.h less in 32-bit mode

Neither clang nor GCC like this very much with -m32: long long ret; asm ("movb $5, %0" : "=q" (ret)); However, GCC can tolerate this variant: long long ret; switch (sizeof(ret)) { case 1: asm ("movb $5, %0" : "=q" (ret)); case 8:

[RFC HACK] Make clang hate percpu.h less in 32-bit mode

Neither clang nor GCC like this very much with -m32: long long ret; asm ("movb $5, %0" : "=q" (ret)); However, GCC can tolerate this variant: long long ret; switch (sizeof(ret)) { case 1: asm ("movb $5, %0" : "=q" (ret)); case 8:

Re: [PATCH] x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes

On Fri, 2018-02-09 at 14:10 +, Darren Kenny wrote: > According to the latest microcode update from Intel (on Feb 8, 2018) on > Skylake we should be using the microcode revisions 0xC2***, so we need > to remove that from the blacklist now. The doc also suggests that Gemini Lake 0x22 is also

Re: [PATCH] x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes

On Fri, 2018-02-09 at 14:10 +, Darren Kenny wrote: > According to the latest microcode update from Intel (on Feb 8, 2018) on > Skylake we should be using the microcode revisions 0xC2***, so we need > to remove that from the blacklist now. The doc also suggests that Gemini Lake 0x22 is also

Re: [PATCH v2] x86/retpoline: Add clang support

mirror/llvm/commit/fd5a8723ce9f2a6b250e85972ef859e4253ea95d > Link: > https://github.com/llvm-mirror/llvm/commit/59b64490fda69d29bb42cfdf7eec37bcc31ff833 > Cc: David Woodhouse <d...@amazon.co.uk> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> >

Re: [PATCH v2] x86/retpoline: Add clang support

mirror/llvm/commit/fd5a8723ce9f2a6b250e85972ef859e4253ea95d > Link: > https://github.com/llvm-mirror/llvm/commit/59b64490fda69d29bb42cfdf7eec37bcc31ff833 > Cc: David Woodhouse > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: gno...@lxorguk.ukuu.org.uk > Cc: Rik van Riel > Cc: Andi Kleen

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, 2018-02-06 at 20:48 +0300, Konstantin Khlebnikov wrote: > On Tue, Feb 6, 2018 at 7:45 PM, David Woodhouse <d...@amazon.co.uk> wrote: > > > > The documentation for ignore_rlimit_data says that it will print a warning > > at first misuse. Yet it doesn't se

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, 2018-02-06 at 20:48 +0300, Konstantin Khlebnikov wrote: > On Tue, Feb 6, 2018 at 7:45 PM, David Woodhouse wrote: > > > > The documentation for ignore_rlimit_data says that it will print a warning > > at first misuse. Yet it doesn't seem to do that. Fix the code to

Re: [PATCH 6/6] s390: introduce execute-trampolines for branches

On Wed, 2018-02-07 at 13:17 +0100, Martin Schwidefsky wrote: > On Wed, 07 Feb 2018 12:07:55 + > David Woodhouse <dw...@infradead.org> wrote: > > > > > On Wed, 2018-02-07 at 11:07 +0100, Pavel Machek wrote: > > > > > > This

Re: [PATCH 6/6] s390: introduce execute-trampolines for branches

On Wed, 2018-02-07 at 13:17 +0100, Martin Schwidefsky wrote: > On Wed, 07 Feb 2018 12:07:55 + > David Woodhouse wrote: > > > > > On Wed, 2018-02-07 at 11:07 +0100, Pavel Machek wrote: > > > > > > This is really unfortunate naming of kernel option.

Re: [PATCH 6/6] s390: introduce execute-trampolines for branches

On Wed, 2018-02-07 at 11:07 +0100, Pavel Machek wrote: > This is really unfortunate naming of kernel option. > > spectre_v2=off sounds like we are turning the "bug" off, but i somehow > suspect you are turning the bug _workaround_ off. That's consistent with what we have on x86. > > +ifdef

Re: [PATCH 6/6] s390: introduce execute-trampolines for branches

On Wed, 2018-02-07 at 11:07 +0100, Pavel Machek wrote: > This is really unfortunate naming of kernel option. > > spectre_v2=off sounds like we are turning the "bug" off, but i somehow > suspect you are turning the bug _workaround_ off. That's consistent with what we have on x86. > > +ifdef

Re: [RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-07 at 12:17 +0100, Borislav Petkov wrote: > Just some random thoughts: > > On Wed, Feb 07, 2018 at 12:03:13AM +0000, David Woodhouse wrote: > > > > +#define alternative_msr_write(_msr, _val, _feature)\ > > +

Re: [RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-07 at 12:17 +0100, Borislav Petkov wrote: > Just some random thoughts: > > On Wed, Feb 07, 2018 at 12:03:13AM +0000, David Woodhouse wrote: > > > > +#define alternative_msr_write(_msr, _val, _feature)\ > > +

[RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 +

[RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm

[RFC PATCH 0/4] Retpoline / IBRS_ALL

dware", but more in the sense that if Intel make hardware like that, then they are Doing It Wrong™. With IBRS_ALL advertised in IA32_ARCH_CAPABILITIES, the IBRS bit in the MSR should do *nothing*. The safe mode where the CPU honours the tags in the BTB/RSB should be enabled *unconditionally*. David

[RFC PATCH 0/4] Retpoline / IBRS_ALL

dware", but more in the sense that if Intel make hardware like that, then they are Doing It Wrong™. With IBRS_ALL advertised in IA32_ARCH_CAPABILITIES, the IBRS bit in the MSR should do *nothing*. The safe mode where the CPU honours the tags in the BTB/RSB should be enabled *unconditionally*. David

[RFC PATCH 4/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ware", but more in the sense that if Intel make hardware like that, then they are Doing It Wrong™. With IBRS_ALL advertised in IA32_ARCH_CAPABILITIES, the IBRS bit in the MSR should do *nothing*. The safe mode where the CPU honours the tags in the BTB/RSB should be enabled *unconditionally*.

[RFC PATCH 4/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ware", but more in the sense that if Intel make hardware like that, then they are Doing It Wrong™. With IBRS_ALL advertised in IA32_ARCH_CAPABILITIES, the IBRS bit in the MSR should do *nothing*. The safe mode where the CPU honours the tags in the BTB/RSB should be enabled *unconditionally*.

[RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

ction call can be optimised away into a direct call and it actually generates slightly smaller code because some of the other conditionals can get optimised away too. Suggested-by: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- a

[RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

ction call can be optimised away into a direct call and it actually generates slightly smaller code because some of the other conditionals can get optimised away too. Suggested-by: Linus Torvalds Signed-off-by: David Woodhouse --- arch/x86/kvm/mmu.c | 10 +- 1 file changed, 5 insert

[RFC PATCH 1/4] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

registers. But no. Just no. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/nospec-branch.h | 13 + arch/x86/include/asm/processor.h | 3 --- arch/x86/kernel/cpu/bugs.c | 6 -- 3 files changed, 9 insertions(+), 13 deletions(-) diff

[RFC PATCH 1/4] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

registers. But no. Just no. Signed-off-by: David Woodhouse --- arch/x86/include/asm/nospec-branch.h | 13 + arch/x86/include/asm/processor.h | 3 --- arch/x86/kernel/cpu/bugs.c | 6 -- 3 files changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/x86/include

Re: [PATCH 2/2] x86/speculation: Simplify indirect_branch_prediction_barrier()

On Tue, 2018-02-06 at 17:25 -0600, Josh Poimboeuf wrote: > On Tue, Feb 06, 2018 at 07:44:52PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote: > > > > > > Make it all a function which does the WRMSR instead o

Re: [PATCH 2/2] x86/speculation: Simplify indirect_branch_prediction_barrier()

On Tue, 2018-02-06 at 17:25 -0600, Josh Poimboeuf wrote: > On Tue, Feb 06, 2018 at 07:44:52PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote: > > > > > > Make it all a function which does the WRMSR instead o

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 10:16 -0800, Tim Chen wrote: > On 02/01/2018 08:51 AM, David Woodhouse wrote: > > No, we just need to set IBRS before doing it. The same applies to any > > EFI runtime calls, APM and all kinds of other random crap that calls > > into firmware. I'm not

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 10:16 -0800, Tim Chen wrote: > On 02/01/2018 08:51 AM, David Woodhouse wrote: > > No, we just need to set IBRS before doing it. The same applies to any > > EFI runtime calls, APM and all kinds of other random crap that calls > > into firmware. I'm not

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote: > > If that is correct (and I might be wrong), then I am up to date and I > am still getting the following in /proc/cpuinfo on my Pentium 4M i686: > > bugs  : cpu_meltdown spectre_v1 spectre_v2 That's expected for now. The CPUs we exempt are

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote: > > If that is correct (and I might be wrong), then I am up to date and I > am still getting the following in /proc/cpuinfo on my Pentium 4M i686: > > bugs  : cpu_meltdown spectre_v1 spectre_v2 That's expected for now. The CPUs we exempt are

Re: [RFC] x86/retpoline: Add clang support for 64-bit builds

On Tue, 2018-02-06 at 12:32 -0800, Guenter Roeck wrote: > > >  > Feedback, anyone ? > > I understand that there is no love for the ABI differences between clang > and gcc, but that doesn't help me. Even if the patch is unacceptable > as-is, I would like to have some feedback to get an idea if I

Re: [RFC] x86/retpoline: Add clang support for 64-bit builds

On Tue, 2018-02-06 at 12:32 -0800, Guenter Roeck wrote: > > >  > Feedback, anyone ? > > I understand that there is no love for the ABI differences between clang > and gcc, but that doesn't help me. Even if the patch is unacceptable > as-is, I would like to have some feedback to get an idea if I

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote: > On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote: > > > > > > > > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote: > > > > > > . > > > > > > &

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote: > On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote: > > > > > > > > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote: > > > > > > . > > > > > > &

Re: [PATCH 2/2] x86/speculation: Simplify indirect_branch_prediction_barrier()

On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote: > Make it all a function which does the WRMSR instead of having a hairy > inline asm. ... > + alternative_input("", > +  "call __ibp_barrier", > +  X86_FEATURE_IBPB, > +  

Re: [PATCH 2/2] x86/speculation: Simplify indirect_branch_prediction_barrier()

On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote: > Make it all a function which does the WRMSR instead of having a hairy > inline asm. ... > + alternative_input("", > +  "call __ibp_barrier", > +  X86_FEATURE_IBPB, > +  

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote: > . > >  > > David > >   I believe I got the patch(es) you mention in in the stable 4.15.1 kernel: > >  > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted > > spectrum related changes" > > (commit

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote: > . > >  > > David > >   I believe I got the patch(es) you mention in in the stable 4.15.1 kernel: > >  > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted > > spectrum related changes" > > (commit

[PATCH 2/9] KVM: nVMX: mark vmcs12 pages dirty on L2 exit

<dmatl...@google.com> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> (cherry picked from commit c9f04407f2e0b3fc9ff7913c65fcfcb0a4b61570) Signed-off-by: David Woodhouse <d...@amazon.co.uk>

[PATCH 2/9] KVM: nVMX: mark vmcs12 pages dirty on L2 exit

-off-by: Radim Krčmář (cherry picked from commit c9f04407f2e0b3fc9ff7913c65fcfcb0a4b61570) Signed-off-by: David Woodhouse --- arch/x86/kvm/vmx.c | 53 +++-- 1 file changed, 43 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86

[PATCH 6/9] KVM/x86: Add IBPB support

k Raj <ashok@intel.com> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: Thomas Gleixner <t...@linutronix.de> Reviewed-by: Konrad Rzeszute

[PATCH 6/9] KVM/x86: Add IBPB support

jlstra (Intel) Signed-off-by: David Woodhouse Signed-off-by: KarimAllah Ahmed Signed-off-by: Thomas Gleixner Reviewed-by: Konrad Rzeszutek Wilk Cc: Andrea Arcangeli Cc: Andi Kleen Cc: k...@vger.kernel.org Cc: Asit Mallick Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Dave Hansen Cc: Arjan Van

[PATCH 4/9] KVM: VMX: introduce alloc_loaded_vmcs

from commit f21f165ef922c2146cc5bdc620f542953c41714b) Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kvm/vmx.c | 38 +++--- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 55b14

[PATCH 4/9] KVM: VMX: introduce alloc_loaded_vmcs

) Signed-off-by: David Woodhouse --- arch/x86/kvm/vmx.c | 38 +++--- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 55b1474..8c562da 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3522,11

[PATCH 1/9] KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail

picked from commit 6342c50ad12e8ce0736e722184a7dbdea4a3477f) Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kvm/vmx.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index feadff3..fd890af 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/

<    1   2   3   4   5   6   7   8   9   10   >