Commit-ID: 5d10cbc91d9eb5537998b65608441b592eec65e7
Gitweb: https://git.kernel.org/tip/5d10cbc91d9eb5537998b65608441b592eec65e7
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:11 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: a5b2966364538a0e68c9fa29bc0a3a1651799035
Gitweb: https://git.kernel.org/tip/a5b2966364538a0e68c9fa29bc0a3a1651799035
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:14 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:18 +0100
x86/cpufeature
Commit-ID: 5d10cbc91d9eb5537998b65608441b592eec65e7
Gitweb: https://git.kernel.org/tip/5d10cbc91d9eb5537998b65608441b592eec65e7
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:11 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:17 +0100
x86/cpufeatures
Commit-ID: 20ffa1caecca4db8f79fe665acdeaa5af815a24d
Gitweb: https://git.kernel.org/tip/20ffa1caecca4db8f79fe665acdeaa5af815a24d
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:15 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 20ffa1caecca4db8f79fe665acdeaa5af815a24d
Gitweb: https://git.kernel.org/tip/20ffa1caecca4db8f79fe665acdeaa5af815a24d
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:15 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:18 +0100
x86/speculation
Commit-ID: 1e340c60d0dd3ae07b5bedc16a0469c14b9f3410
Gitweb: https://git.kernel.org/tip/1e340c60d0dd3ae07b5bedc16a0469c14b9f3410
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:12 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 1e340c60d0dd3ae07b5bedc16a0469c14b9f3410
Gitweb: https://git.kernel.org/tip/1e340c60d0dd3ae07b5bedc16a0469c14b9f3410
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:12 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:17 +0100
x86/msr: Add
On Fri, 2018-01-26 at 13:11 +0100, Borislav Petkov wrote:
>
> +ENTRY(__fill_rsb_clobber_ax)
> + ___FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS, %_ASM_SP
> +END(__fill_rsb_clobber_ax)
> +EXPORT_SYMBOL_GPL(__fill_rsb_clobber_ax)
You still have clear vs. fill confusion there.
How about
On Fri, 2018-01-26 at 13:11 +0100, Borislav Petkov wrote:
>
> +ENTRY(__fill_rsb_clobber_ax)
> + ___FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS, %_ASM_SP
> +END(__fill_rsb_clobber_ax)
> +EXPORT_SYMBOL_GPL(__fill_rsb_clobber_ax)
You still have clear vs. fill confusion there.
How about
On Fri, 2018-01-26 at 13:14 +0100, Yves-Alexis Perez wrote:
> On Wed, 2018-01-24 at 16:57 +0000, David Woodhouse wrote:
> > 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, ar
On Fri, 2018-01-26 at 13:16 +0100, Yves-Alexis Perez wrote:
> On Wed, 2018-01-24 at 16:57 +0000, David Woodhouse wrote:
> > We don't refuse to load the affected microcodes; just refuse to use
> > SPEC_CTRL
> > if they're detected.
>
> Hi David,
>
> Are we
On Fri, 2018-01-26 at 13:14 +0100, Yves-Alexis Perez wrote:
> On Wed, 2018-01-24 at 16:57 +0000, David Woodhouse wrote:
> > 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, ar
On Fri, 2018-01-26 at 13:16 +0100, Yves-Alexis Perez wrote:
> On Wed, 2018-01-24 at 16:57 +0000, David Woodhouse wrote:
> > We don't refuse to load the affected microcodes; just refuse to use
> > SPEC_CTRL
> > if they're detected.
>
> Hi David,
>
> Are we
rislav Petkov <b...@alien8.de>
> Cc: Josh Poimboeuf <jpoim...@redhat.com>
>
> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Thank you for pandering to my paranoia. I suspect that misspelling the
word 'retarded' isn't going to be sufficient to stop people fr
Poimboeuf
>
> Signed-off-by: Peter Zijlstra (Intel)
Thank you for pandering to my paranoia. I suspect that misspelling the
word 'retarded' isn't going to be sufficient to stop people from
objecting to the use of that word, but other than that,
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> This is boot code, we run this _way_ before userspace comes along to
> poison our branch predictor.
Hm, objtool knows about sections, doesn't it? Why it is whining about
indirect jumps in inittext anyway?
In fact, why are we even *doing*
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> This is boot code, we run this _way_ before userspace comes along to
> poison our branch predictor.
Hm, objtool knows about sections, doesn't it? Why it is whining about
indirect jumps in inittext anyway?
In fact, why are we even *doing*
ra (Intel) <pet...@infradead.org>
Reviewed-by: David Woodhouse <d...@amazon.co.uk>
> ---
> arch/x86/kernel/head_64.S |2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -23,6 +23,7 @@
> #in
tel)
Reviewed-by: David Woodhouse
> ---
> arch/x86/kernel/head_64.S |2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -23,6 +23,7 @@
> #include
> #include "../entry/calling.h"
>
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Annotate the indirect calls/jumps in the CALL_NOSPEC/JUMP_NOSPEC
> alternatives.
>
>
> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Reviewed-by: David Woodhouse <d...@amazon.co.uk>
However..
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Annotate the indirect calls/jumps in the CALL_NOSPEC/JUMP_NOSPEC
> alternatives.
>
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: David Woodhouse
However...
> /*
> + * This should be used immediate
On Thu, 2018-01-25 at 12:35 +0100, Peter Zijlstra wrote:
> On Thu, Jan 25, 2018 at 10:52:53AM +0000, David Woodhouse wrote:
> >
> > OK, my brain hurts a bit but I'm happy now. Thank you.
> OK, I've updated the Changelog thusly. Is this satisfactory?
>
> ---
> Subj
On Thu, 2018-01-25 at 12:35 +0100, Peter Zijlstra wrote:
> On Thu, Jan 25, 2018 at 10:52:53AM +0000, David Woodhouse wrote:
> >
> > OK, my brain hurts a bit but I'm happy now. Thank you.
> OK, I've updated the Changelog thusly. Is this satisfactory?
>
> ---
> Subj
ls are subject to the same
speculation?
Other than that, which you can probably ignore if you didn't have to
explicitly annotate [m]any safe far calls anyway,
Reviewed-by: David Woodhouse <d...@amazon.co.uk>
Thanks for doing this.
smime.p7s
Description: S/MIME cryptographic signature
ls are subject to the same
speculation?
Other than that, which you can probably ignore if you didn't have to
explicitly annotate [m]any safe far calls anyway,
Reviewed-by: David Woodhouse
Thanks for doing this.
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2018-01-25 at 18:23 -0800, Dave Hansen wrote:
> On 01/25/2018 06:11 PM, Liran Alon wrote:
> >
> > It is true that attacker cannot speculate to a kernel-address, but it
> > doesn't mean it cannot use the leaked kernel-address together with
> > another unrelated vulnerability to build a
On Thu, 2018-01-25 at 18:23 -0800, Dave Hansen wrote:
> On 01/25/2018 06:11 PM, Liran Alon wrote:
> >
> > It is true that attacker cannot speculate to a kernel-address, but it
> > doesn't mean it cannot use the leaked kernel-address together with
> > another unrelated vulnerability to build a
On Thu, 2018-01-25 at 18:11 -0800, Liran Alon wrote:
>
> P.S:
> It seems to me that all these issues could be resolved completely at
> hardware in future CPUs if BTB/BHB/RSB entries were tagged with
> prediction-mode (or similar metadata). It will be nice if Intel/AMD
> could share if that is the
On Thu, 2018-01-25 at 18:11 -0800, Liran Alon wrote:
>
> P.S:
> It seems to me that all these issues could be resolved completely at
> hardware in future CPUs if BTB/BHB/RSB entries were tagged with
> prediction-mode (or similar metadata). It will be nice if Intel/AMD
> could share if that is the
On Thu, 2018-01-25 at 18:53 +0100, Borislav Petkov wrote:
>
> So forget the KABI angle and think: simpler, cleaner, more readable
> macros.
>
> Oh, and David, if while doing so I manage to add the alignment, then
> *that* is even better.
>
> Win-win-effing-win situation!
Yep, I'll buy that.
On Thu, 2018-01-25 at 18:53 +0100, Borislav Petkov wrote:
>
> So forget the KABI angle and think: simpler, cleaner, more readable
> macros.
>
> Oh, and David, if while doing so I manage to add the alignment, then
> *that* is even better.
>
> Win-win-effing-win situation!
Yep, I'll buy that.
On Thu, 2018-01-25 at 10:56 -0600, Josh Poimboeuf wrote:
> On Thu, Jan 25, 2018 at 04:03:18PM +0000, David Woodhouse wrote:
> > On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote:
> > >
> > > > And the seg fault is objtool's way of telling you you need a
>
On Thu, 2018-01-25 at 10:56 -0600, Josh Poimboeuf wrote:
> On Thu, Jan 25, 2018 at 04:03:18PM +0000, David Woodhouse wrote:
> > On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote:
> > >
> > > > And the seg fault is objtool's way of telling you you need a
>
On Thu, 2018-01-25 at 17:24 +0100, Thomas Gleixner wrote:
> On Thu, 25 Jan 2018, Alan Cox wrote:
>
> >
> > >
> > > Here's what I have now. I'm happy enough with this, so the main thing
> > > I'm looking for is an ack from Alan for patch #5 of the series, if I've
> > > got that sufficiently
On Thu, 2018-01-25 at 17:24 +0100, Thomas Gleixner wrote:
> On Thu, 25 Jan 2018, Alan Cox wrote:
>
> >
> > >
> > > Here's what I have now. I'm happy enough with this, so the main thing
> > > I'm looking for is an ack from Alan for patch #5 of the series, if I've
> > > got that sufficiently
in microcode blacklist table.
v5: Update bad KBL microcode revision, blacklist all new features.
Add NSC to no_speculation list.
David Woodhouse (7):
x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
x86/cpufeatures: Add Intel feature bits for Speculation Control
x86/cpufeatures: Add AMD feature
in microcode blacklist table.
v5: Update bad KBL microcode revision, blacklist all new features.
Add NSC to no_speculation list.
David Woodhouse (7):
x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
x86/cpufeatures: Add Intel feature bits for Speculation Control
x86/cpufeatures: Add AMD feature
Add three feature bits exposed by new microcode on Intel CPUs for
speculation control.
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Reviewed-by: Borislav Petkov <b...@suse.de>
---
arch/x86/include/asm/cpufea
Add three feature bits exposed by new microcode on Intel CPUs for
speculation control.
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm
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>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/include/asm
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
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/include/asm/msr-index.h | 12
1 file changed, 12 insertions
, for fine-grained control
of what's available.
It is non-trivial to use x86_match_cpu() for this table because that
doesn't handle steppings. And the approach taken in commit bd9240a18
almost made me lose my lunch.
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Greg Kroah-Hartma
, for fine-grained control
of what's available.
It is non-trivial to use x86_match_cpu() for this table because that
doesn't handle steppings. And the approach taken in commit bd9240a18
almost made me lose my lunch.
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu
-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: KarimAllah Ahmed <karah...@amazon.de>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/nospec-branch.h | 13 +
arch/x86/kernel/cpu/bugs.c
-by: Thomas Gleixner
Signed-off-by: KarimAllah Ahmed
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/nospec-branch.h | 13 +
arch/x86/kernel/cpu/bugs.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/arch/x86/include
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: Greg Kroah-Hartma
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: Greg Kroah-Hartman
Reviewed-by: Borislav Petkov
.
Based on suggestions from Dave Hansen and Alan Cox.
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/kernel/cpu/common.c | 48 +++-
1 file changed, 43 insertions(+),
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>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/include/asm/c
.
Based on suggestions from Dave Hansen and Alan Cox.
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/common.c | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b
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
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
diff
On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote:
>
> > And the seg fault is objtool's way of telling you you need a
> > ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-)
>
> Except that it blew up when I did this which doesn't have ALTERNATIVE
> (it's the diff I saved :-))
Yeah,
On Thu, 2018-01-25 at 16:51 +0100, Borislav Petkov wrote:
>
> > And the seg fault is objtool's way of telling you you need a
> > ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-)
>
> Except that it blew up when I did this which doesn't have ALTERNATIVE
> (it's the diff I saved :-))
Yeah,
date-guidance-20180124.pdf
Here's what I have now. I'm happy enough with this, so the main thing
I'm looking for is an ack from Alan for patch #5 of the series, if I've
got that sufficiently correct now.
From ad16c9a9f459a91c0980a2c7fde41640b6c04524 Mon Sep 17 00:00:00 2001
From: David Woodhouse <
date-guidance-20180124.pdf
Here's what I have now. I'm happy enough with this, so the main thing
I'm looking for is an ack from Alan for patch #5 of the series, if I've
got that sufficiently correct now.
From ad16c9a9f459a91c0980a2c7fde41640b6c04524 Mon Sep 17 00:00:00 2001
From: David Woodhouse
Dat
On Thu, 2018-01-25 at 13:07 +0100, Borislav Petkov wrote:
> On Fri, Jan 12, 2018 at 03:37:49AM -0800, tip-bot for David Woodhouse wrote:
> >
> > +/*
> > + * On VMEXIT we must ensure that no RSB predictions learned in the guest
> > + * can be followed in the host, by ove
On Thu, 2018-01-25 at 13:07 +0100, Borislav Petkov wrote:
> On Fri, Jan 12, 2018 at 03:37:49AM -0800, tip-bot for David Woodhouse wrote:
> >
> > +/*
> > + * On VMEXIT we must ensure that no RSB predictions learned in the guest
> > + * can be followed in the host, by ove
On Thu, 2018-01-25 at 13:03 +0100, Borislav Petkov wrote:
> On Thu, Jan 25, 2018 at 11:58:20AM +0000, David Woodhouse wrote:
> > They're immediates, not registers. So it's like the first example
> in...
>
> Oh, I know very well what they are - I simply find the mac
On Thu, 2018-01-25 at 13:03 +0100, Borislav Petkov wrote:
> On Thu, Jan 25, 2018 at 11:58:20AM +0000, David Woodhouse wrote:
> > They're immediates, not registers. So it's like the first example
> in...
>
> Oh, I know very well what they are - I simply find the mac
On Thu, 2018-01-25 at 12:50 +0100, Borislav Petkov wrote:
> On Thu, Jan 25, 2018 at 11:47:35AM +0000, David Woodhouse wrote:
> > I did already do the explicit clobbers now you reminded me how to do
> > them, but I elected not to use ASM_NO_INPUT_CLOBBER() because on
>
On Thu, 2018-01-25 at 12:50 +0100, Borislav Petkov wrote:
> On Thu, Jan 25, 2018 at 11:47:35AM +0000, David Woodhouse wrote:
> > I did already do the explicit clobbers now you reminded me how to do
> > them, but I elected not to use ASM_NO_INPUT_CLOBBER() because on
>
On Thu, 2018-01-25 at 12:41 +0100, Borislav Petkov wrote:
>
> > +static inline void indirect_branch_prediction_barrier(void)
> > +{
> > + asm volatile(ALTERNATIVE("",
> > + "movl %[msr], %%ecx\n\t"
> > + "movl %[val], %%eax\n\t"
> > +
On Thu, 2018-01-25 at 12:41 +0100, Borislav Petkov wrote:
>
> > +static inline void indirect_branch_prediction_barrier(void)
> > +{
> > + asm volatile(ALTERNATIVE("",
> > + "movl %[msr], %%ecx\n\t"
> > + "movl %[val], %%eax\n\t"
> > +
On Thu, 2018-01-25 at 11:54 +0100, Thomas Gleixner wrote:
> On Thu, 25 Jan 2018, David Woodhouse wrote:
>
> >
> > On Thu, 2018-01-25 at 09:23 +0000, David Woodhouse wrote:
> > >
> > >
> > > +/*
> > > + * Early microcode releases for the Sp
On Thu, 2018-01-25 at 11:54 +0100, Thomas Gleixner wrote:
> On Thu, 25 Jan 2018, David Woodhouse wrote:
>
> >
> > On Thu, 2018-01-25 at 09:23 +0000, David Woodhouse wrote:
> > >
> > >
> > > +/*
> > > + * Early microcode releases for the Sp
On Thu, 2018-01-25 at 11:26 +0100, Juergen Gross wrote:
> On 25/01/18 11:22, Peter Zijlstra wrote:
> >
> > On Thu, Jan 25, 2018 at 10:02:05AM +, David Woodhouse wrote:
> > >
> > > On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> > > >
On Thu, 2018-01-25 at 11:26 +0100, Juergen Gross wrote:
> On 25/01/18 11:22, Peter Zijlstra wrote:
> >
> > On Thu, Jan 25, 2018 at 10:02:05AM +, David Woodhouse wrote:
> > >
> > > On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> > > >
On Thu, 2018-01-25 at 09:23 +, David Woodhouse wrote:
>
> +/*
> + * Early microcode releases for the Spectre v2 mitigation were broken.
> + * Information taken from;
> + * •
> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf
O
On Thu, 2018-01-25 at 09:23 +, David Woodhouse wrote:
>
> +/*
> + * Early microcode releases for the Spectre v2 mitigation were broken.
> + * Information taken from;
> + * •
> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf
O
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Paravirt emits indirect calls which get flagged by objtool retpoline
> checks, annotate it away because all these indirect calls will be
> patched out before we start userspace.
I've seen this asserted repeatedly but I've never truly
On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> Paravirt emits indirect calls which get flagged by objtool retpoline
> checks, annotate it away because all these indirect calls will be
> patched out before we start userspace.
I've seen this asserted repeatedly but I've never truly
On Thu, 2018-01-25 at 10:42 +0100, Peter Zijlstra wrote:
> On Thu, Jan 25, 2018 at 09:23:07AM +0000, David Woodhouse wrote:
> > +static bool __init early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c)
> > +{
> > + u64 ia32_cap = 0;
> > +
> > +
On Thu, 2018-01-25 at 10:42 +0100, Peter Zijlstra wrote:
> On Thu, Jan 25, 2018 at 09:23:07AM +0000, David Woodhouse wrote:
> > +static bool __init early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c)
> > +{
> > + u64 ia32_cap = 0;
> > +
> > +
On Thu, 2018-01-25 at 10:34 +0100, Peter Zijlstra wrote:
> On Wed, Jan 24, 2018 at 11:43:05AM +0100, Paolo Bonzini wrote:
> >
> > On 24/01/2018 11:35, Peter Zijlstra wrote:
> > >
> > > On Tue, Jan 23, 2018 at 08:48:13PM +, David Woodhouse wrote:
> > &
On Thu, 2018-01-25 at 10:34 +0100, Peter Zijlstra wrote:
> On Wed, Jan 24, 2018 at 11:43:05AM +0100, Paolo Bonzini wrote:
> >
> > On 24/01/2018 11:35, Peter Zijlstra wrote:
> > >
> > > On Tue, Jan 23, 2018 at 08:48:13PM +, David Woodhouse wrote:
> > &
-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: KarimAllah Ahmed <karah...@amazon.de>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/nospec-branch.h | 13 +
arch/x86/kernel/cpu/bugs.c
-by: Thomas Gleixner
Signed-off-by: KarimAllah Ahmed
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/nospec-branch.h | 13 +
arch/x86/kernel/cpu/bugs.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/arch/x86/include
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>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/include/asm/c
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
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
diff
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/kernel/cpu/intel.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/ke
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/intel.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b720dac..4af572d 100644
--- a/arch/x86/
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>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/include/asm
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
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/include/asm/msr-index.h | 12
1 file changed, 12 insertions
Add three feature bits exposed by new microcode on Intel CPUs for
speculation control.
Signed-off-by: David Woodhouse <dw...@infradead.org>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Reviewed-by: Borislav Petkov <b...@suse.de>
---
arch/x86/include/asm/cpufea
.
Based on suggestions from Dave Hansen and Alan Cox.
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/kernel/cpu/common.c | 47 +++-
1 file changed, 42 insertions(+),
Add three feature bits exposed by new microcode on Intel CPUs for
speculation control.
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm
.
Based on suggestions from Dave Hansen and Alan Cox.
Signed-off-by: David Woodhouse
Reviewed-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/common.c | 47 +++-
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b
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: Greg Kroah-Hartma
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: Greg Kroah-Hartman
Reviewed-by: Borislav Petkov
in microcode blacklist table.
David Woodhouse (7):
x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
x86/cpufeatures: Add Intel feature bits for Speculation Control
x86/cpufeatures: Add AMD feature bits for Speculation Control
x86/msr: Add definitions for new speculation control MSRs
x86/pti: Do
in microcode blacklist table.
David Woodhouse (7):
x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
x86/cpufeatures: Add Intel feature bits for Speculation Control
x86/cpufeatures: Add AMD feature bits for Speculation Control
x86/msr: Add definitions for new speculation control MSRs
x86/pti: Do
On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
> It is possible that the last uesr mm that we recorded for a cpu was
> released, and a new mm with identical address was allocated when we
> check it again. We could skip IBPB flush here for the process with
> the new mm.
>
> It is a difficult
On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
> It is possible that the last uesr mm that we recorded for a cpu was
> released, and a new mm with identical address was allocated when we
> check it again. We could skip IBPB flush here for the process with
> the new mm.
>
> It is a difficult
> > >
> > > Bisection points to
> > >
> > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit
> > > commit f3433c1010c6af61c9897f0f0447f81b991feac1
> > > Author: David Woodhouse <d...@amazon.co.uk>
> > > Date: Tue Jan 9 14:43:11 2018 +0
; > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit
> > > commit f3433c1010c6af61c9897f0f0447f81b991feac1
> > > Author: David Woodhouse
> > > Date: Tue Jan 9 14:43:11 2018 +
> > >
> > > x
How about...
static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
How about...
static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
On Wed, 2018-01-24 at 10:17 -0800, Andi Kleen wrote:
> +/* A module has been loaded. Disable reporting that we're good. */
> +void disable_retpoline(void)
> +{
> + spectre_v2_enabled = SPECTRE_V2_NONE;
That wants to be one of the 'MINIMAL' variants.
> + pr_err("system may be
On Wed, 2018-01-24 at 10:17 -0800, Andi Kleen wrote:
> +/* A module has been loaded. Disable reporting that we're good. */
> +void disable_retpoline(void)
> +{
> + spectre_v2_enabled = SPECTRE_V2_NONE;
That wants to be one of the 'MINIMAL' variants.
> + pr_err("system may be
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.
801 - 900 of 4023 matches
Mail list logo
