ing the offending CPU online.
So ensure that the appropriate feature bits are set within get_cpu_cap()
regardless of how many extra times it's called.
Signed-off-by: David Woodhouse
Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags")
---
So...
We now understand wh
On Tue, 2018-01-30 at 12:37 +0100, Thomas Gleixner wrote:
> In any case, if there is ucode mismatch between CPUs the whole thing is
> hosed anyway no matter what. So can you please agree on a solution so we
> can unbreak the current state of affairs?
If there is µcode mismatch between CPUs then
On Tue, 2018-01-30 at 12:37 +0100, Thomas Gleixner wrote:
> In any case, if there is ucode mismatch between CPUs the whole thing is
> hosed anyway no matter what. So can you please agree on a solution so we
> can unbreak the current state of affairs?
If there is µcode mismatch between CPUs then
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
>
> Note on the unhappiness with some of the patches involved: what I do
> *not* want to see is the "on every kernel entry" kind of garbage.
>
> So my unhappiness with the intel microcode patches is two-fold:
>
> (a) the interface is
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
>
> Note on the unhappiness with some of the patches involved: what I do
> *not* want to see is the "on every kernel entry" kind of garbage.
>
> So my unhappiness with the intel microcode patches is two-fold:
>
> (a) the interface is
On Tue, 2018-01-30 at 12:18 +0100, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 11:03:50AM +0000, David Woodhouse wrote:
> >
> > I pondered that, but I didn't like it. I didn't want to always *force*
> > those features on, for all CPUs, just because they happened
On Tue, 2018-01-30 at 12:18 +0100, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 11:03:50AM +0000, David Woodhouse wrote:
> >
> > I pondered that, but I didn't like it. I didn't want to always *force*
> > those features on, for all CPUs, just because they happened
On Tue, 2018-01-30 at 11:58 +0100, Borislav Petkov wrote:
>
> Does that help?
>
> diff --git a/arch/x86/kernel/cpu/intel.c
> b/arch/x86/kernel/cpu/intel.c
> index 6936d14d4c77..1dd596d0a6c4 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -182,21 +182,21 @@
On Tue, 2018-01-30 at 11:58 +0100, Borislav Petkov wrote:
>
> Does that help?
>
> diff --git a/arch/x86/kernel/cpu/intel.c
> b/arch/x86/kernel/cpu/intel.c
> index 6936d14d4c77..1dd596d0a6c4 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -182,21 +182,21 @@
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
> Add direct access to speculation control MSRs for KVM guests. This allows the
> guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
> retpoline+IBPB based approach.
>
> It also exposes the ARCH_CAPABILITIES MSR
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
> Add direct access to speculation control MSRs for KVM guests. This allows the
> guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
> retpoline+IBPB based approach.
>
> It also exposes the ARCH_CAPABILITIES MSR
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
> And the "big hammer" approach to spectre would seem to
> be to just make sure the BTB and RSB are flushed at vmexit time - and
> even then you might decide that you really want to just move it to
> vmenter time, and only do it if the VM
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
> And the "big hammer" approach to spectre would seem to
> be to just make sure the BTB and RSB are flushed at vmexit time - and
> even then you might decide that you really want to just move it to
> vmenter time, and only do it if the VM
for bad microcode can use setup_clear_cpu_cap()
to force them off for all CPUs; I was less keen on forcing the feature
bits *on* that way.
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags")
---
I feel I
for bad microcode can use setup_clear_cpu_cap()
to force them off for all CPUs; I was less keen on forcing the feature
bits *on* that way.
Signed-off-by: David Woodhouse
Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags")
---
I feel I must be missing something. I
pointer recycling.
Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/include/asm/tlbflush.h | 2 ++
arch/x86/mm/tlb.c | 33 -
2 files changed, 34 insertions(+), 1 deletion(-)
by: Tim Chen
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/tlbflush.h | 2 ++
arch/x86/mm/tlb.c | 33 -
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 3eff
On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
> On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
> >
> > The question is how the hypervisor could tell that to the guest.
> > If Intel doesn't give us a CPUID bit that can be used to tell
> > that retpolines are enough, maybe we should
On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
> On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
> >
> > The question is how the hypervisor could tell that to the guest.
> > If Intel doesn't give us a CPUID bit that can be used to tell
> > that retpolines are enough, maybe we should
On Mon, 2018-01-29 at 18:14 -0200, Eduardo Habkost wrote:
>
> Sorry for being confused here, as probably the answer is buried
> on a LKML thread somewhere. The comment explains what the code
> does, but not why. Why exactly IBRS is preferred on Skylake?
>
> I'm asking this because I would like
On Mon, 2018-01-29 at 18:14 -0200, Eduardo Habkost wrote:
>
> Sorry for being confused here, as probably the answer is buried
> on a LKML thread somewhere. The comment explains what the code
> does, but not why. Why exactly IBRS is preferred on Skylake?
>
> I'm asking this because I would like
nux-foundation.org>
> > Cc: Tim Chen <tim.c.c...@linux.intel.com>
> > Cc: Thomas Gleixner <t...@linutronix.de>
> > Cc: Dan Williams <dan.j.willi...@intel.com>
> > Cc: Jun Nakajima <jun.nakaj...@intel.com>
> > Cc: Paolo Bonzini <pbonz...@redhat.com
n Van De Ven
> > Cc: Dave Hansen
> > Cc: Andi Kleen
> > Cc: Andrea Arcangeli
> > Cc: Linus Torvalds
> > Cc: Tim Chen
> > Cc: Thomas Gleixner
> > Cc: Dan Williams
> > Cc: Jun Nakajima
> > Cc: Paolo Bonzini
> > Cc: David Woodhouse
On Mon, 2018-01-29 at 11:58 -0600, Josh Poimboeuf wrote:
> On Tue, Jan 23, 2018 at 04:25:42PM +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
On Mon, 2018-01-29 at 11:58 -0600, Josh Poimboeuf wrote:
> On Tue, Jan 23, 2018 at 04:25:42PM +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
On Mon, 2018-01-29 at 15:28 +0100, Paolo Bonzini wrote:
> On 29/01/2018 13:53, David Woodhouse wrote:
> >
> > Hm, we are pushing the other bits through tip/x86/pti, which is still
> > based on 4.14 so that everything can be backported easily. I was
> > expecting to b
On Mon, 2018-01-29 at 15:28 +0100, Paolo Bonzini wrote:
> On 29/01/2018 13:53, David Woodhouse wrote:
> >
> > Hm, we are pushing the other bits through tip/x86/pti, which is still
> > based on 4.14 so that everything can be backported easily. I was
> > expecting to b
On Sat, 2018-01-27 at 09:50 +0100, Paolo Bonzini wrote:
> David and others,
>
> the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6:
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26
> 09:03:16 -0800)
>
> are available in the git
On Sat, 2018-01-27 at 09:50 +0100, Paolo Bonzini wrote:
> David and others,
>
> the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6:
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26
> 09:03:16 -0800)
>
> are available in the git
On Mon, 2018-01-29 at 13:28 +0100, Dominik Brodowski wrote:
> The commit message is much more about the A->idle-> improvement than
> on the basic design decisions to limit this to non-dumpable processes.
Yeah, I collapsed the commit messages from the three commits into one.
But the resulting
On Mon, 2018-01-29 at 13:28 +0100, Dominik Brodowski wrote:
> The commit message is much more about the A->idle-> improvement than
> on the basic design decisions to limit this to non-dumpable processes.
Yeah, I collapsed the commit messages from the three commits into one.
But the resulting
pointer recycling.
Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
How close are we to done with bikeshedding this one?...
arch/x86/include/asm/tlbflush.h | 2 ++
arch/x86/mm/tlb.c | 31 ++
by: Tim Chen
Signed-off-by: David Woodhouse
---
How close are we to done with bikeshedding this one?...
arch/x86/include/asm/tlbflush.h | 2 ++
arch/x86/mm/tlb.c | 31 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/
On Mon, 2018-01-29 at 12:19 +0100, Martin Steigerwald wrote:
>
> The whole thing works:
>
> % grep . /sys/devices/system/cpu/vulnerabilities/*
>
> /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
>
On Mon, 2018-01-29 at 12:19 +0100, Martin Steigerwald wrote:
>
> The whole thing works:
>
> % grep . /sys/devices/system/cpu/vulnerabilities/*
>
> /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
>
On Mon, 2018-01-29 at 10:43 +0100, KarimAllah Ahmed wrote:
> On 01/29/2018 09:46 AM, David Woodhouse wrote:
> > Reading the code and comparing with the SDM, I can't see where we're
> > ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested
> > case...
> Hmmm ... y
On Mon, 2018-01-29 at 10:43 +0100, KarimAllah Ahmed wrote:
> On 01/29/2018 09:46 AM, David Woodhouse wrote:
> > Reading the code and comparing with the SDM, I can't see where we're
> > ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested
> > case...
> Hmmm ... y
On Mon, 2018-01-29 at 10:41 +0100, Martin Steigerwald wrote:
> From what I read gcc 7.3 was supposed to include back ported retpoline
> patches. What am I missing here?
Which did you update first? Kernel source or GCC?
Try removing .cache.mk which has 'remembered' that your GCC doesn't
support
On Mon, 2018-01-29 at 10:41 +0100, Martin Steigerwald wrote:
> From what I read gcc 7.3 was supposed to include back ported retpoline
> patches. What am I missing here?
Which did you update first? Kernel source or GCC?
Try removing .cache.mk which has 'remembered' that your GCC doesn't
support
On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
>
> Windows use IBRS and Microsoft don't have any plans to switch to retpoline.
> Running a Windows guest should be a pretty common use-case no?
>
> In addition, your handle of the first WRMSR intercept could be different.
> It could signal
On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
>
> Windows use IBRS and Microsoft don't have any plans to switch to retpoline.
> Running a Windows guest should be a pretty common use-case no?
>
> In addition, your handle of the first WRMSR intercept could be different.
> It could signal
..@linutronix.de>
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Jun Nakajima <jun.nakaj...@intel.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>
> Cc: David Woodhouse <d...@amazon.co.uk>
> Cc: Greg KH <gre...@linuxfoundation.org>
> Cc: Andy Lut
; Cc: Linus Torvalds
> Cc: Tim Chen
> Cc: Thomas Gleixner
> Cc: Dan Williams
> Cc: Jun Nakajima
> Cc: Paolo Bonzini
> Cc: David Woodhouse
> Cc: Greg KH
> Cc: Andy Lutomirski
> Cc: Ashok Raj
> Signed-off-by: KarimAllah Ahmed
>
> ---
> v2:
> - rem
>>
>> On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
>> >
>> > Do you mean that the host would intercept the guest WRMSR and do
>> > WRMSR itself? I would suggest that doing so is inconsistent with the
>> > docs. As specified, doing WRMSR to write 1 to IBRS does *not*
>> > protect
>>
>> On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
>> >
>> > Do you mean that the host would intercept the guest WRMSR and do
>> > WRMSR itself? I would suggest that doing so is inconsistent with the
>> > docs. As specified, doing WRMSR to write 1 to IBRS does *not*
>> > protect
On Sun, 2018-01-28 at 12:53 -0800, Andy Lutomirski wrote:
>
> > I believe it does. Guest kernel is protected from any guest userspace
> > predictions learned before IBRS was last set to 1 in *any* mode,
> > including host.
>
> Hmm, you're probably right.
>
> I would love to know what awful hack
On Sun, 2018-01-28 at 12:53 -0800, Andy Lutomirski wrote:
>
> > I believe it does. Guest kernel is protected from any guest userspace
> > predictions learned before IBRS was last set to 1 in *any* mode,
> > including host.
>
> Hmm, you're probably right.
>
> I would love to know what awful hack
On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
>
> Do you mean that the host would intercept the guest WRMSR and do
> WRMSR itself? I would suggest that doing so is inconsistent with the
> docs. As specified, doing WRMSR to write 1 to IBRS does *not*
> protect the guest.
I believe
On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
>
> Do you mean that the host would intercept the guest WRMSR and do
> WRMSR itself? I would suggest that doing so is inconsistent with the
> docs. As specified, doing WRMSR to write 1 to IBRS does *not*
> protect the guest.
I believe
On Sun, 2018-01-28 at 15:21 -0500, Konrad Rzeszutek Wilk wrote:
> >To avoid the overhead of atomically saving and restoring the
> >MSR_IA32_SPEC_CTRL
> >for guests that do not actually use the MSR, only add_atomic_switch_msr when
> >a
> >non-zero is written to it.
>
>
> We tried this and found
On Sun, 2018-01-28 at 15:21 -0500, Konrad Rzeszutek Wilk wrote:
> >To avoid the overhead of atomically saving and restoring the
> >MSR_IA32_SPEC_CTRL
> >for guests that do not actually use the MSR, only add_atomic_switch_msr when
> >a
> >non-zero is written to it.
>
>
> We tried this and found
Commit-ID: 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2
Gitweb: https://git.kernel.org/tip/2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Sat, 27 Jan 2018 16:24:32 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2
Gitweb: https://git.kernel.org/tip/2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2
Author: David Woodhouse
AuthorDate: Sat, 27 Jan 2018 16:24:32 +
Committer: Thomas Gleixner
CommitDate: Sat, 27 Jan 2018 19:10:44 +0100
x86/cpufeatures
d
like PTI does just because we're using it for ALTERNATIVEs, is renamed
to X86_FEATURE_USE_IBPB.
Based on patches from Borislav Petkov <b...@suse.de>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/include/asm/cpufeatures.h | 18 +-
arch/x86/include/asm/nospec-branch.
d
like PTI does just because we're using it for ALTERNATIVEs, is renamed
to X86_FEATURE_USE_IBPB.
Based on patches from Borislav Petkov
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/cpufeatures.h | 18 +-
arch/x86/include/asm/nospec-branch.h | 2 +-
arch/x86/kernel/cpu/bugs.c
From: Borislav Petkov <b...@suse.de>
Make it all a function which does the WRMSR instead of having a hairy
inline asm.
[dwmw2: export it, fix CONFIG_RETPOLINE issues]
Signed-off-by: Borislav Petkov <b...@suse.de>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/
t tell the compiler]
Signed-off-by: Borislav Petkov <b...@suse.de>
Signed-off-by: David Woodhouse <d...@amazon.co.uk>
---
arch/x86/entry/entry_32.S | 3 +-
arch/x86/entry/entry_64.S | 3 +-
arch/x86/include/asm/asm-prototypes.h | 3 ++
arch/x86/include/asm/nos
From: Borislav Petkov
Make it all a function which does the WRMSR instead of having a hairy
inline asm.
[dwmw2: export it, fix CONFIG_RETPOLINE issues]
Signed-off-by: Borislav Petkov
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/nospec-branch.h | 13 -
arch/x86/include
-off-by: Borislav Petkov
Signed-off-by: David Woodhouse
---
arch/x86/entry/entry_32.S | 3 +-
arch/x86/entry/entry_64.S | 3 +-
arch/x86/include/asm/asm-prototypes.h | 3 ++
arch/x86/include/asm/nospec-branch.h | 70 ---
arch/x86/lib
blocks and simplify backports to older kernels, so tweak
and apply his patches for that too.
Borislav Petkov (2):
x86/retpoline: Simplify vmexit_fill_RSB()
x86/speculation: Simplify indirect_branch_prediction_barrier()
David Woodhouse (1):
x86/cpufeatures: Clean up Spectre v2 related CPUID fla
blocks and simplify backports to older kernels, so tweak
and apply his patches for that too.
Borislav Petkov (2):
x86/retpoline: Simplify vmexit_fill_RSB()
x86/speculation: Simplify indirect_branch_prediction_barrier()
David Woodhouse (1):
x86/cpufeatures: Clean up Spectre v2 related CPUID fla
On Sat, 2018-01-27 at 08:59 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 05:14:37PM +0100, Peter Zijlstra wrote:
> >
> > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >
> > > >
> > > > a good suggestion, but we encountered some issues with it either
> > >
On Sat, 2018-01-27 at 08:59 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 05:14:37PM +0100, Peter Zijlstra wrote:
> >
> > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >
> > > >
> > > > a good suggestion, but we encountered some issues with it either
> > >
On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote:
>
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -971,4 +971,8 @@ bool xen_set_default_idle(void);
>
> void stop_this_cpu(void *dummy);
> void df_debug(struct pt_regs *regs, long error_code);
> +
On Fri, 2018-01-26 at 21:08 +0100, Borislav Petkov wrote:
>
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -971,4 +971,8 @@ bool xen_set_default_idle(void);
>
> void stop_this_cpu(void *dummy);
> void df_debug(struct pt_regs *regs, long error_code);
> +
On Sat, 2018-01-27 at 10:37 +0100, Borislav Petkov wrote:
> On Sat, Jan 27, 2018 at 09:27:48AM +0000, David Woodhouse wrote:
> >
> > http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
> > tree?
> @@ -223,7 +223,7 @@ static inline void
> indirect_bra
On Sat, 2018-01-27 at 10:37 +0100, Borislav Petkov wrote:
> On Sat, Jan 27, 2018 at 09:27:48AM +0000, David Woodhouse wrote:
> >
> > http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
> > tree?
> @@ -223,7 +223,7 @@ static inline void
> indirect_bra
http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
tree?
I'll rework that into the series instead of as a patch on top...
smime.p7s
Description: S/MIME cryptographic signature
http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
tree?
I'll rework that into the series instead of as a patch on top...
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2018-01-26 at 17:14 -0600, Tom Lendacky wrote:
> On 1/26/2018 4:10 PM, Borislav Petkov wrote:
> >
> > On Fri, Jan 26, 2018 at 09:59:44PM +, David Woodhouse wrote:
> > >
> > > If we wanted to do this kind of thing, we'd do it the other way roun
On Fri, 2018-01-26 at 17:14 -0600, Tom Lendacky wrote:
> On 1/26/2018 4:10 PM, Borislav Petkov wrote:
> >
> > On Fri, Jan 26, 2018 at 09:59:44PM +, David Woodhouse wrote:
> > >
> > > If we wanted to do this kind of thing, we'd do it the other way roun
On Fri, 2018-01-26 at 22:52 +0100, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 03:06:20PM -0600, Tom Lendacky wrote:
> >
> > So I like the idea of AMD_IBRS/AMD_IBPB/AMD_STIBP and then use the magic
> > quotes as appropriate. We could probably use the magic quotes on
> > AMD_STIBP and set
On Fri, 2018-01-26 at 22:52 +0100, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 03:06:20PM -0600, Tom Lendacky wrote:
> >
> > So I like the idea of AMD_IBRS/AMD_IBPB/AMD_STIBP and then use the magic
> > quotes as appropriate. We could probably use the magic quotes on
> > AMD_STIBP and set
On Fri, 2018-01-26 at 14:02 -0500, Konrad Rzeszutek Wilk wrote:
>
> -ECONFUSED, see ==>
>
> Is this incorrect then?
> I see:
>
> 241 * Skylake era CPUs have a separate issue with *underflow* of the
>
> 242 * RSB, when they will predict 'ret' targets from the generic
>
On Fri, 2018-01-26 at 14:02 -0500, Konrad Rzeszutek Wilk wrote:
>
> -ECONFUSED, see ==>
>
> Is this incorrect then?
> I see:
>
> 241 * Skylake era CPUs have a separate issue with *underflow* of the
>
> 242 * RSB, when they will predict 'ret' targets from the generic
>
On Fri, 2018-01-26 at 18:44 +, Van De Ven, Arjan wrote:
> your question was specific to RSB not BTB. But please show the empirical
> evidence for RSB ?
We were hypothesising, which should have been clear from:
On Fri, 2018-01-26 at 09:11 +, David Woodhouse wrote:
> Likewise i
On Fri, 2018-01-26 at 18:44 +, Van De Ven, Arjan wrote:
> your question was specific to RSB not BTB. But please show the empirical
> evidence for RSB ?
We were hypothesising, which should have been clear from:
On Fri, 2018-01-26 at 09:11 +, David Woodhouse wrote:
> Likewise i
On Fri, 2018-01-26 at 19:41 +0100, Borislav Petkov wrote:
> +#define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch
> Prediction Barrier MSR */
Stray quotes.
> +#define X86_FEATURE_IBRS (13*32+14) /* Indirect Branch
> Restricted Speculation */
Please don't call
On Fri, 2018-01-26 at 19:41 +0100, Borislav Petkov wrote:
> +#define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch
> Prediction Barrier MSR */
Stray quotes.
> +#define X86_FEATURE_IBRS (13*32+14) /* Indirect Branch
> Restricted Speculation */
Please don't call
On Fri, 2018-01-26 at 18:28 +, Van De Ven, Arjan wrote:
> > As you know well, I mean "we think Intel's document is not
> > correct".
>
> you asked before and even before you sent the email I confirmed to
> you that the document is correct
>
> I'm not sure what the point is to then question
On Fri, 2018-01-26 at 18:28 +, Van De Ven, Arjan wrote:
> > As you know well, I mean "we think Intel's document is not
> > correct".
>
> you asked before and even before you sent the email I confirmed to
> you that the document is correct
>
> I'm not sure what the point is to then question
On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> On 1/26/2018 10:11 AM, David Woodhouse wrote:
> >
> > I am *actively* ignoring Skylake right now. This is about per-SKL
> > userspace even with SMEP, because we think Intel's document lies to us.
>
> if you
On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> On 1/26/2018 10:11 AM, David Woodhouse wrote:
> >
> > I am *actively* ignoring Skylake right now. This is about per-SKL
> > userspace even with SMEP, because we think Intel's document lies to us.
>
> if you
On Fri, 2018-01-26 at 09:59 -0800, Andi Kleen wrote:
> On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote:
> >
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse wrote:
> > >
> > >
> > > Do we need to look again at the fact that we've
On Fri, 2018-01-26 at 09:59 -0800, Andi Kleen wrote:
> On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote:
> >
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse wrote:
> > >
> > >
> > > Do we need to look again at the fact that we've
On Fri, 2018-01-26 at 17:29 +, David Woodhouse wrote:
> On Fri, 2018-01-26 at 09:19 -0800, Linus Torvalds wrote:
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse <dw...@infradead.org>
> > wrote:
> > > Do we need to look again at the fact that we've di
On Fri, 2018-01-26 at 17:29 +, David Woodhouse wrote:
> On Fri, 2018-01-26 at 09:19 -0800, Linus Torvalds wrote:
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse
> > wrote:
> > > Do we need to look again at the fact that we've disabled the RSB-
> > > stuf
On Fri, 2018-01-26 at 09:19 -0800, Linus Torvalds wrote:
> On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse <dw...@infradead.org> wrote:
> >
> >
> > Do we need to look again at the fact that we've disabled the RSB-
> > stuffing for SMEP?
> Absolutely. SMEP
On Fri, 2018-01-26 at 09:19 -0800, Linus Torvalds wrote:
> On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse wrote:
> >
> >
> > Do we need to look again at the fact that we've disabled the RSB-
> > stuffing for SMEP?
> Absolutely. SMEP helps make people a
On Fri, 2018-01-26 at 14:24 +0100, Borislav Petkov wrote:
> diff --git a/arch/x86/include/asm/asm-prototypes.h
> b/arch/x86/include/asm/asm-prototypes.h
> index 1908214b9125..b889705f995a 100644
> --- a/arch/x86/include/asm/asm-prototypes.h
> +++ b/arch/x86/include/asm/asm-prototypes.h
> @@ -38,4
On Fri, 2018-01-26 at 14:24 +0100, Borislav Petkov wrote:
> diff --git a/arch/x86/include/asm/asm-prototypes.h
> b/arch/x86/include/asm/asm-prototypes.h
> index 1908214b9125..b889705f995a 100644
> --- a/arch/x86/include/asm/asm-prototypes.h
> +++ b/arch/x86/include/asm/asm-prototypes.h
> @@ -38,4
On Fri, 2018-01-26 at 07:02 -0800, tip-bot for David Woodhouse wrote:
> + boot_cpu_has(X86_FEATURE_IBPB) ? ", IPBP" :
s/IPBP/IBPB/
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2018-01-26 at 07:02 -0800, tip-bot for David Woodhouse wrote:
> + boot_cpu_has(X86_FEATURE_IBPB) ? ", IPBP" :
s/IPBP/IBPB/
smime.p7s
Description: S/MIME cryptographic signature
Commit-ID: fec9434a12f38d3aeafeb75711b71d8a1fdef621
Gitweb: https://git.kernel.org/tip/fec9434a12f38d3aeafeb75711b71d8a1fdef621
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:13 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: fec9434a12f38d3aeafeb75711b71d8a1fdef621
Gitweb: https://git.kernel.org/tip/fec9434a12f38d3aeafeb75711b71d8a1fdef621
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:13 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:18 +0100
x86/pti: Do
Commit-ID: fc67dd70adb711a45d2ef34e12d1a8be75edde61
Gitweb: https://git.kernel.org/tip/fc67dd70adb711a45d2ef34e12d1a8be75edde61
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:10 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: fc67dd70adb711a45d2ef34e12d1a8be75edde61
Gitweb: https://git.kernel.org/tip/fc67dd70adb711a45d2ef34e12d1a8be75edde61
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:10 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:16 +0100
x86/cpufeatures
Commit-ID: 95ca0ee8636059ea2800dfbac9ecac6212d6b38f
Gitweb: https://git.kernel.org/tip/95ca0ee8636059ea2800dfbac9ecac6212d6b38f
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:09 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
Commit-ID: 95ca0ee8636059ea2800dfbac9ecac6212d6b38f
Gitweb: https://git.kernel.org/tip/95ca0ee8636059ea2800dfbac9ecac6212d6b38f
Author: David Woodhouse
AuthorDate: Thu, 25 Jan 2018 16:14:09 +
Committer: Thomas Gleixner
CommitDate: Fri, 26 Jan 2018 15:53:16 +0100
x86/cpufeatures
Commit-ID: a5b2966364538a0e68c9fa29bc0a3a1651799035
Gitweb: https://git.kernel.org/tip/a5b2966364538a0e68c9fa29bc0a3a1651799035
Author: David Woodhouse <d...@amazon.co.uk>
AuthorDate: Thu, 25 Jan 2018 16:14:14 +
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate:
701 - 800 of 4023 matches
Mail list logo
