Re: [PATCH v2] KVM: x86: allow compiling out the Xen hypercall interface

On Fri, 2021-02-26 at 06:57 -0500, Paolo Bonzini wrote: > + depends on KVM && IA32_FEAT_CTL Hm, why IA32_FEAT_CTL? Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street,

Re: [PATCH v2] KVM: x86: allow compiling out the Xen hypercall interface

On Fri, 2021-02-26 at 06:57 -0500, Paolo Bonzini wrote: > The Xen hypercall interface adds to the attack surface of the hypervisor > and will be used quite rarely. Allow compiling it out. > > Suggested-by: Christoph Hellwig > Cc: David Woodhouse > Signed-off-by: Paolo Bonzini Reviewed-by:

Re: [PATCH] KVM: flush deferred static key before checking it

On Fri, 2021-02-26 at 05:08 -0500, Paolo Bonzini wrote: > A missing flush would cause the static branch to trigger incorrectly. > > Cc: David Woodhouse > Signed-off-by: Paolo Bonzini Reviewed-by: David Woodhouse Thanks. Amazon Development Centre (London) Ltd. Registered in England and

Re: [PATCH 5/5] KVM: x86/xen: Explicitly pad struct compat_vcpu_info to 64 bytes

On Wed, 2021-02-10 at 13:13 -0800, Sean Christopherson wrote: > On Wed, Feb 10, 2021, Woodhouse, David wrote: > > On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote: > > So it isn't clear the additionally padding really buys us anything; if > > we play this game wi

Re: [PATCH 3/5] KVM: selftests: Fix hex vs. decimal snafu in Xen test

On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote: > The Xen shinfo selftest uses '40' when setting the GPA of the vCPU info > struct, but checks for the result at '0x40'. Arbitrarily use the hex > version to resolve the bug. > > Fixes: 8d4e7e80838f ("KVM: x86: declare Xen HVM shared

Re: [PATCH 5/5] KVM: x86/xen: Explicitly pad struct compat_vcpu_info to 64 bytes

On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote: > Add a 2 byte pad to struct compat_vcpu_info so that the sum size of its > fields is actually 64 bytes. The effective size without the padding is > also 64 bytes due to the compiler aligning evtchn_pending_sel to a 4-byte > boundary,

Re: [PATCH] arm/xen: Don't probe xenbus as part of an early initcall

On Wed, 2021-02-10 at 17:06 +, Julien Grall wrote: > From: Julien Grall > > After Commit 3499ba8198cad ("xen: Fix event channel callback via > INTX/GSI"), xenbus_probe() will be called too early on Arm. This will > recent to a guest hang during boot. > > If there hang wasn't there, we would

Re: [PATCH] KVM: x86/xen: Use hva_t for holding hypercall page address

On Mon, 2021-02-08 at 12:15 -0800, Sean Christopherson wrote: > Use hva_t, a.k.a. unsigned long, for the local variable that holds the > hypercall page address. On 32-bit KVM, gcc complains about using a u64 > due to the implicit cast from a 64-bit value to a 32-bit pointer. > >

Re: [PATCH] iommu/hyper-v: Fix panic on a host without the 15-bit APIC ID support

On Tue, 2020-12-01 at 16:45 -0800, Dexuan Cui wrote: > The commit f36a74b9345a itself is good, but it causes a panic in a > Linux VM that runs on a Hyper-V host that doesn't have the 15-bit > Extended APIC ID support: > kernel BUG at arch/x86/kernel/apic/io_apic.c:2408! > > This happens

Re: [x86/ioapic] b643128b91: Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC

On Tue, 2020-11-03 at 16:22 +0100, Thomas Gleixner wrote: > Hi! > > On Tue, Nov 03 2020 at 22:31, lkp wrote: > > FYI, we noticed the following commit (built with gcc-9): > > > > commit: b643128b917ca8f1c8b1e14af64ebdc81147b2d1 ("x86/ioapic: Use > > irq_find_matching_fwspec() to find remapping

Re: [PATCH 0/2] Backport IBPB on context switch to non-dumpable process

On Sat, 2018-03-03 at 09:54 +0100, Greg Kroah-Hartman wrote: > On Fri, Mar 02, 2018 at 01:32:08PM -0800, Tim Chen wrote: > > > > Greg, > > > > I will like to propose backporting "x86/speculation: Use Indirect Branch > > Prediction Barrier on context switch" from commit 18bf3c3e in upstream > >

Re: [PATCH 0/2] Backport IBPB on context switch to non-dumpable process

On Sat, 2018-03-03 at 09:54 +0100, Greg Kroah-Hartman wrote: > On Fri, Mar 02, 2018 at 01:32:08PM -0800, Tim Chen wrote: > > > > Greg, > > > > I will like to propose backporting "x86/speculation: Use Indirect Branch > > Prediction Barrier on context switch" from commit 18bf3c3e in upstream > >

Re: [STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

On Tue, 2018-02-06 at 19:01 +0100, Paolo Bonzini wrote: > On 06/02/2018 18:29, David Woodhouse wrote: > > I've put together a linux-4.9.y branch at  > > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9.y > >  > > Most of it is fairly straightforward, apart from the

Re: [STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

On Tue, 2018-02-06 at 19:01 +0100, Paolo Bonzini wrote: > On 06/02/2018 18:29, David Woodhouse wrote: > > I've put together a linux-4.9.y branch at  > > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9.y > >  > > Most of it is fairly straightforward, apart from the

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:05 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote: > > > Yes, but how would moving the field into struct loaded_vmcs do anything? > >  Only vmon/vmoff would change anything in vmx->nested.vmcs02. > > My suggestion

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:05 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote: > > > Yes, but how would moving the field into struct loaded_vmcs do anything? > >  Only vmon/vmoff would change anything in vmx->nested.vmcs02. > > My suggestion was that

Re: [PATCH v2] x86/ibpb: Skip IBPB when we switch back to same user process

On Sun, 2018-01-28 at 10:56 +0100, Ingo Molnar wrote: > > What tree is this patch against? It doesn't apply to linus's latest, nor to  > tip:master. It's in my tree at   http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb which is gradually being finalized and

Re: [PATCH v2] x86/ibpb: Skip IBPB when we switch back to same user process

On Sun, 2018-01-28 at 10:56 +0100, Ingo Molnar wrote: > > What tree is this patch against? It doesn't apply to linus's latest, nor to  > tip:master. It's in my tree at   http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb which is gradually being finalized and

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

On Tue, 2018-01-23 at 17:28 -0800, Dave Hansen wrote: > On 01/23/2018 05:23 PM, Woodhouse, David wrote: > > > > On Tue, 2018-01-23 at 10:43 -0800, Dave Hansen wrote: > ... > > > > > > > > > > > > >   /* Intel-defined CPU f

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

On Tue, 2018-01-23 at 17:28 -0800, Dave Hansen wrote: > On 01/23/2018 05:23 PM, Woodhouse, David wrote: > > > > On Tue, 2018-01-23 at 10:43 -0800, Dave Hansen wrote: > ... > > > > > > > > > > > > >   /* Intel-defined CPU f

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

On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: > > Not sure.  Maybe to start, the answer might be to allow it to be set for > > the ultra-paranoid, but in general don't enable it by default.  Having it > > enabled would be an alternative to someone deciding to disable SMT, since > > that

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

On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: > > Not sure.  Maybe to start, the answer might be to allow it to be set for > > the ultra-paranoid, but in general don't enable it by default.  Having it > > enabled would be an alternative to someone deciding to disable SMT, since > > that

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

On Tue, 2018-01-23 at 10:41 -0800, Dave Hansen wrote: > On 01/23/2018 08:52 AM, 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. > > Also, I hate to ask...  Have you tested this patch? Nope. I

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

On Tue, 2018-01-23 at 10:41 -0800, Dave Hansen wrote: > On 01/23/2018 08:52 AM, 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. > > Also, I hate to ask...  Have you tested this patch? Nope. I

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

On Tue, 2018-01-23 at 19:31 +0100, Greg KH wrote: > On Tue, Jan 23, 2018 at 10:27:24AM -0800, Dave Hansen wrote: > > > > On 01/23/2018 08:52 AM, David Woodhouse wrote: > > > > > > +#define MSR_IA32_ARCH_CAPABILITIES 0x010a > > > +#define ARCH_CAP_RDCL_NO (1 << 0)   /* Not

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

On Tue, 2018-01-23 at 19:31 +0100, Greg KH wrote: > On Tue, Jan 23, 2018 at 10:27:24AM -0800, Dave Hansen wrote: > > > > On 01/23/2018 08:52 AM, David Woodhouse wrote: > > > > > > +#define MSR_IA32_ARCH_CAPABILITIES 0x010a > > > +#define ARCH_CAP_RDCL_NO (1 << 0)   /* Not

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

On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote: > > >> +.macro UNRESTRICT_IB_SPEC > >> +    ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS > >> +    PUSH_MSR_REGS > >> +    WRMSR_ASM $MSR_IA32_SPEC_CTRL, $0, $0 > >  > I think you should be writing 2, not 0, since I'm reasonably >

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

On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote: > > >> +.macro UNRESTRICT_IB_SPEC > >> +    ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS > >> +    PUSH_MSR_REGS > >> +    WRMSR_ASM $MSR_IA32_SPEC_CTRL, $0, $0 > >  > I think you should be writing 2, not 0, since I'm reasonably >

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

On Mon, 2018-01-22 at 14:30 +0100, Greg Kroah-Hartman wrote: > We kind of do, you can submit patches to UEFI, but I doubt that the > processor-specific portions are actually present in the Tianocore code > to be able to be patched. This is just about which microcode your BIOS loads into the CPU

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

On Mon, 2018-01-22 at 14:30 +0100, Greg Kroah-Hartman wrote: > We kind of do, you can submit patches to UEFI, but I doubt that the > processor-specific portions are actually present in the Tianocore code > to be able to be patched. This is just about which microcode your BIOS loads into the CPU

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

On Sun, 2018-01-21 at 17:21 +0100, Ingo Molnar wrote: > > Because putting something like this into an ELF flag raises the question of > who is  > allowed to set the flag - does a user-compiled binary count? If yes then it > would  > be a trivial thing for local exploits to set the flag and turn

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

On Sun, 2018-01-21 at 17:21 +0100, Ingo Molnar wrote: > > Because putting something like this into an ELF flag raises the question of > who is  > allowed to set the flag - does a user-compiled binary count? If yes then it > would  > be a trivial thing for local exploits to set the flag and turn

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

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > From: Tim Chen I think this is probably From: Andi now rather than From: Tim? We do need the series this far in order to have a full retpoline-based mitigation, and I'd like to see that go in sooner rather

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

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > From: Tim Chen I think this is probably From: Andi now rather than From: Tim? We do need the series this far in order to have a full retpoline-based mitigation, and I'd like to see that go in sooner rather than later. There's a little

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 12:28 -0800, Liran Alon wrote: > Isn't it cleaner to check for "boot_cpu_has(X86_FEATURE_IBPB)" both > in svm_vcpu_init_msrpm() and hardware_setup()? Strictly speaking that's a different check. That's checking if we're *using* IBPB, not if it exists. Now that's probably OK

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 12:28 -0800, Liran Alon wrote: > Isn't it cleaner to check for "boot_cpu_has(X86_FEATURE_IBPB)" both > in svm_vcpu_init_msrpm() and hardware_setup()? Strictly speaking that's a different check. That's checking if we're *using* IBPB, not if it exists. Now that's probably OK

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > > @@ -6791,6 +6792,9 @@ static __init int hardware_setup(void) > kvm_tsc_scaling_ratio_frac_bits = 48; > } >   > +   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) > +   

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > > @@ -6791,6 +6792,9 @@ static __init int hardware_setup(void) > kvm_tsc_scaling_ratio_frac_bits = 48; > } >   > +   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) > +   

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can apply the

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can apply the

Re: [PATCH v1 tip/master 1/3] retpoline: Introduce start/end markers of indirect thunk

On Thu, 2018-01-18 at 21:01 +0900, Masami Hiramatsu wrote: > > +#define X86_INDIRECT_THUNK(reg)\ > +   *(.text.__x86.indirect_thunk.##reg) Note that we don't actually care about those being in their own section, named after the register. That was just a hangover from the

Re: [PATCH v1 tip/master 1/3] retpoline: Introduce start/end markers of indirect thunk

On Thu, 2018-01-18 at 21:01 +0900, Masami Hiramatsu wrote: > > +#define X86_INDIRECT_THUNK(reg)\ > +   *(.text.__x86.indirect_thunk.##reg) Note that we don't actually care about those being in their own section, named after the register. That was just a hangover from the

Re: [PATCH 4.9 85/96] x86/retpoline: Add initial retpoline support

On Tue, 2018-01-16 at 11:22 +0100, Jiri Slaby wrote: > On 01/15/2018, 01:35 PM, Greg Kroah-Hartman wrote: > > 4.9-stable review patch.  If anyone has any objections, please let me know. > > May I ask if somebody has started the 4.4 port yet? Razvan pushed that out yesterday:

Re: [PATCH 4.9 85/96] x86/retpoline: Add initial retpoline support

On Tue, 2018-01-16 at 11:22 +0100, Jiri Slaby wrote: > On 01/15/2018, 01:35 PM, Greg Kroah-Hartman wrote: > > 4.9-stable review patch.  If anyone has any objections, please let me know. > > May I ask if somebody has started the 4.4 port yet? Razvan pushed that out yesterday:

Re: [PATCH v2] x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros

On Sun, 2018-01-14 at 16:41 +0100, Borislav Petkov wrote: > On Sat, Jan 13, 2018 at 05:27:30PM -0600, Tom Lendacky wrote: > > > > The PAUSE instruction is currently used in the retpoline and RSB filling > > macros as a speculation trap.  The use of PAUSE was originally suggested > > because it

Re: [PATCH v2] x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros

On Sun, 2018-01-14 at 16:41 +0100, Borislav Petkov wrote: > On Sat, Jan 13, 2018 at 05:27:30PM -0600, Tom Lendacky wrote: > > > > The PAUSE instruction is currently used in the retpoline and RSB filling > > macros as a speculation trap.  The use of PAUSE was originally suggested > > because it

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On Fri, 2018-01-12 at 19:07 -0600, Tom Lendacky wrote: > The pause instruction is currently used in the retpoline and RSB filling > macros as a speculation trap.  The use of pause was originally suggested > because it showed a very, very small difference in the amount of > cycles/time used to

Re: [PATCH v1] x86/retpoline: Use lfence in the retpoline/RSB filling RSB macros

On Fri, 2018-01-12 at 19:07 -0600, Tom Lendacky wrote: > The pause instruction is currently used in the retpoline and RSB filling > macros as a speculation trap.  The use of pause was originally suggested > because it showed a very, very small difference in the amount of > cycles/time used to

Re: [PATCH 4/8] kvm: vmx: Set IBPB when running a different VCPU

On Fri, 2018-01-12 at 09:03 -0800, Jim Mattson wrote: > The point behind the IPBP in vmx_vcpu_load is to prevent one VCPU from > steering the speculative execution of the next. If the VMCS address is > recycled, vmx_vcpu_load doesn't realize that the VCPUs are different, > and so it won't issue

Re: [PATCH 4/8] kvm: vmx: Set IBPB when running a different VCPU

On Fri, 2018-01-12 at 09:03 -0800, Jim Mattson wrote: > The point behind the IPBP in vmx_vcpu_load is to prevent one VCPU from > steering the speculative execution of the next. If the VMCS address is > recycled, vmx_vcpu_load doesn't realize that the VCPUs are different, > and so it won't issue

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, 2018-01-11 at 21:03 -0800, Dave Hansen wrote: > On 01/11/2018 07:01 PM, Raj, Ashok wrote: > > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: > >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > > What's wrong with native_read_msr()? >

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, 2018-01-11 at 21:03 -0800, Dave Hansen wrote: > On 01/11/2018 07:01 PM, Raj, Ashok wrote: > > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote: > >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote: > > What's wrong with native_read_msr()? > >>> > >>> Yes, i

Re: [PATCH 5/5] x86/feature: Detect the x86 feature Indirect Branch Prediction Barrier

On Fri, 2018-01-12 at 09:31 -0600, Tom Lendacky wrote: > > AMD will follow the specification that if cpuid ax=0x7, return rdx[26] > is set, it will indicate both MSR registers and features are supported. > > But AMD also has a separate bit for IBPB (X86_FEATURE_PRED_CMD) alone. > As all of the

Re: [PATCH 5/5] x86/feature: Detect the x86 feature Indirect Branch Prediction Barrier

On Fri, 2018-01-12 at 09:31 -0600, Tom Lendacky wrote: > > AMD will follow the specification that if cpuid ax=0x7, return rdx[26] > is set, it will indicate both MSR registers and features are supported. > > But AMD also has a separate bit for IBPB (X86_FEATURE_PRED_CMD) alone. > As all of the

Re: [PATCH 5/5] x86/feature: Detect the x86 feature Indirect Branch Prediction Barrier

On Fri, 2018-01-12 at 13:32 +0100, Borislav Petkov wrote: > On Thu, Jan 11, 2018 at 05:32:19PM -0800, Ashok Raj wrote: > > cpuid ax=0x7, return rdx bit 26 to indicate presence of both > > IA32_SPEC_CTRL(MSR 0x48) and IA32_PRED_CMD(MSR 0x49) > > So why do we need two X86_FEATURE flags then? AMD

Re: [PATCH 5/5] x86/feature: Detect the x86 feature Indirect Branch Prediction Barrier

On Fri, 2018-01-12 at 13:32 +0100, Borislav Petkov wrote: > On Thu, Jan 11, 2018 at 05:32:19PM -0800, Ashok Raj wrote: > > cpuid ax=0x7, return rdx bit 26 to indicate presence of both > > IA32_SPEC_CTRL(MSR 0x48) and IA32_PRED_CMD(MSR 0x49) > > So why do we need two X86_FEATURE flags then? AMD

Re: [PATCH v8.1 12/12] x86/retpoline: Fill return stack buffer on vmexit

> On Fri, 2018-01-12 at 12:15 +0100, Thomas Gleixner wrote: > Fair enough. I surely like the below way more than the sloppy hackery from > Andi which completely removed any form of documentation. Be nice. Andi has been extremely helpful in testing and finding corner cases here, and generally

Re: [PATCH v8.1 12/12] x86/retpoline: Fill return stack buffer on vmexit

> On Fri, 2018-01-12 at 12:15 +0100, Thomas Gleixner wrote: > Fair enough. I surely like the below way more than the sloppy hackery from > Andi which completely removed any form of documentation. Be nice. Andi has been extremely helpful in testing and finding corner cases here, and generally

Re: [PATCH v3 3/5] x86/enter: Use IBRS on syscall and interrupts

On Tue, 2018-01-09 at 18:26 -0800, Tim Chen wrote: > Set IBRS upon kernel entrance via syscall and interrupts. Clear it > upon exit.  In the former set of sites, you're going to want to stuff the RSB too. The patch I sent out this morning adds the infrastructure you want for that; we'll just want

Re: [PATCH v3 3/5] x86/enter: Use IBRS on syscall and interrupts

On Tue, 2018-01-09 at 18:26 -0800, Tim Chen wrote: > Set IBRS upon kernel entrance via syscall and interrupts. Clear it > upon exit.  In the former set of sites, you're going to want to stuff the RSB too. The patch I sent out this morning adds the infrastructure you want for that; we'll just want

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-11 at 10:47 +0100, Borislav Petkov wrote: > On Thu, Jan 11, 2018 at 10:32:31AM +0100, Peter Zijlstra wrote: > > > > can't you do lovely things like: > > > > volatile asm ("call __fill_rsb_thunk_%1" : : "r" (dummy)) > > > > which would still let gcc select the register ?

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-11 at 10:47 +0100, Borislav Petkov wrote: > On Thu, Jan 11, 2018 at 10:32:31AM +0100, Peter Zijlstra wrote: > > > > can't you do lovely things like: > > > > volatile asm ("call __fill_rsb_thunk_%1" : : "r" (dummy)) > > > > which would still let gcc select the register ?

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-11 at 09:49 +0100, Boris Petkov wrote: > On January 11, 2018 9:42:38 AM GMT+01:00, Peter Zijlstra wrote: > >Or we teach the alternative thing to patch in a jmp to end instead of > >NOP padding the entire thing as soon as the jmp (3 bytes) fits ? > > Or, even better: use

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Thu, 2018-01-11 at 09:49 +0100, Boris Petkov wrote: > On January 11, 2018 9:42:38 AM GMT+01:00, Peter Zijlstra wrote: > >Or we teach the alternative thing to patch in a jmp to end instead of > >NOP padding the entire thing as soon as the jmp (3 bytes) fits ? > > Or, even better: use

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Wed, 2018-01-10 at 15:47 -0800, Tim Chen wrote: > > > + > > + asm volatile (ALTERNATIVE("", > > +   __stringify(__FILL_RETURN_BUFFER(%0, %1, > > _%=)), > > +   X86_FEATURE_RETPOLINE) > > We'll be patching in a fairly long set of

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Wed, 2018-01-10 at 15:47 -0800, Tim Chen wrote: > > > + > > + asm volatile (ALTERNATIVE("", > > +   __stringify(__FILL_RETURN_BUFFER(%0, %1, > > _%=)), > > +   X86_FEATURE_RETPOLINE) > > We'll be patching in a fairly long set of

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Wed, 2018-01-10 at 15:22 -0800, David Lang wrote: > I somewhat hate to ask this, but for those of us following at home, what does  > this add to the overhead? > > I am remembering an estimate from mid last week that put retpoline at > replacing  > a 3 clock 'ret' with 30 clocks of eye-bleed

Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit

On Wed, 2018-01-10 at 15:22 -0800, David Lang wrote: > I somewhat hate to ask this, but for those of us following at home, what does  > this add to the overhead? > > I am remembering an estimate from mid last week that put retpoline at > replacing  > a 3 clock 'ret' with 30 clocks of eye-bleed

Re: tip/master falls off NOP cliff with KPTI under KVM

On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: > > Bisection points to > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit > commit f3433c1010c6af61c9897f0f0447f81b991feac1 > Author: David Woodhouse > Date:   Tue Jan

Re: tip/master falls off NOP cliff with KPTI under KVM

On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: > > Bisection points to > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit > commit f3433c1010c6af61c9897f0f0447f81b991feac1 > Author: David Woodhouse > Date:   Tue Jan 9 14:43:11 2018

Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest

On Wed, 2018-01-10 at 10:41 -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 10, 2018 at 03:28:43PM +0100, Paolo Bonzini wrote: > > On 10/01/2018 15:06, Arjan van de Ven wrote: > > > On 1/10/2018 5:20 AM, Paolo Bonzini wrote: > > >> * a simple specification that does "IBRS=1 blocks indirect >

Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest

On Wed, 2018-01-10 at 10:41 -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 10, 2018 at 03:28:43PM +0100, Paolo Bonzini wrote: > > On 10/01/2018 15:06, Arjan van de Ven wrote: > > > On 1/10/2018 5:20 AM, Paolo Bonzini wrote: > > >> * a simple specification that does "IBRS=1 blocks indirect >

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, 2018-01-08 at 02:42 -0800, Paul Turner wrote: > > While the cases above involve the crafting and use of poisoned > entries.  Recall also that one of the initial conditions was that we > should avoid RSB underflow as some CPUs may try to use other indirect > predictors when this occurs. I

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, 2018-01-08 at 02:42 -0800, Paul Turner wrote: > > While the cases above involve the crafting and use of poisoned > entries.  Recall also that one of the initial conditions was that we > should avoid RSB underflow as some CPUs may try to use other indirect > predictors when this occurs. I

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Wed, 2018-01-10 at 09:18 -0600, Tom Lendacky wrote: > > Ok, hence my caveat on the underflow in the reply.  If it's to eliminate > userspace addresses, then yes, it needs to be applied for AMD as well. > > In that case maybe the comments in arch/x86/entry/entry_{32,64}.S need to > be updated

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Wed, 2018-01-10 at 09:18 -0600, Tom Lendacky wrote: > > Ok, hence my caveat on the underflow in the reply.  If it's to eliminate > userspace addresses, then yes, it needs to be applied for AMD as well. > > In that case maybe the comments in arch/x86/entry/entry_{32,64}.S need to > be updated

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Wed, 2018-01-10 at 08:23 -0600, Tom Lendacky wrote: > On 1/10/2018 7:15 AM, Woodhouse, David wrote: > > On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > >> From: Andi Kleen <a...@linux.intel.com> > >> > >> X86_FEATURE_RETPOLINE has bee

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Wed, 2018-01-10 at 08:23 -0600, Tom Lendacky wrote: > On 1/10/2018 7:15 AM, Woodhouse, David wrote: > > On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > >> From: Andi Kleen > >> > >> X86_FEATURE_RETPOLINE has been renamed to X86_FEATURE_RETPOLINE_GENER

Re: [PATCH v3 2/3] x86/retpoline: Use better sequences for NOSPEC_CALL/JMP

On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > From: Andi Kleen > > [This fixes a boot failure in the earlier patches > so may want to be moved earlier to keep git bisect > happy] > > With the latest tip x86/pti I get oopses when booting > a 64bit VM in qemu with

Re: [PATCH v3 2/3] x86/retpoline: Use better sequences for NOSPEC_CALL/JMP

On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > From: Andi Kleen > > [This fixes a boot failure in the earlier patches > so may want to be moved earlier to keep git bisect > happy] > > With the latest tip x86/pti I get oopses when booting > a 64bit VM in qemu with RETPOLINE/gcc7 and PTI

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > From: Andi Kleen > > X86_FEATURE_RETPOLINE has been renamed to X86_FEATURE_RETPOLINE_GENERIC. > Convert the sequences using it. AMD documentation says they need the RSB fill too, so these should stay under

Re: [PATCH v3 3/3] x86/retpoline: Convert generic specific retpolines to use RETPOLINE_GENERIC

On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote: > From: Andi Kleen > > X86_FEATURE_RETPOLINE has been renamed to X86_FEATURE_RETPOLINE_GENERIC. > Convert the sequences using it. AMD documentation says they need the RSB fill too, so these should stay under X86_FEATURE_RETPOLINE I think.

Re: [PATCH v6 01/10] x86/retpoline: Add initial retpoline support

On Tue, 2018-01-09 at 13:36 +0100, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 02:46:32PM +0100, Thomas Gleixner wrote: > > On Mon, 8 Jan 2018, Josh Poimboeuf wrote: > > > > I wonder if an error might be more appropriate than a warning.  I > > > learned from experience that a lot of people

Re: [PATCH v6 01/10] x86/retpoline: Add initial retpoline support

On Tue, 2018-01-09 at 13:36 +0100, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 02:46:32PM +0100, Thomas Gleixner wrote: > > On Mon, 8 Jan 2018, Josh Poimboeuf wrote: > > > > I wonder if an error might be more appropriate than a warning.  I > > > learned from experience that a lot of people

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch II

On Mon, 2018-01-08 at 17:21 -0800, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote: > > > If we clear the registers, what the hell are you going to put in the > > > RSB that helps you? > >  > > RSB allows you to control chains of gadgets. > > I admit the gadget

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch II

On Mon, 2018-01-08 at 17:21 -0800, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote: > > > If we clear the registers, what the hell are you going to put in the > > > RSB that helps you? > >  > > RSB allows you to control chains of gadgets. > > I admit the gadget

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 16:15 -0800, Paul Turner wrote: > On Mon, Jan 8, 2018 at 2:11 PM, Peter Zijlstra wrote: > > On Mon, Jan 08, 2018 at 12:15:31PM -0800, Andi Kleen wrote: > >> diff --git a/arch/x86/include/asm/nospec-branch.h > >> b/arch/x86/include/asm/nospec-branch.h >

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 16:15 -0800, Paul Turner wrote: > On Mon, Jan 8, 2018 at 2:11 PM, Peter Zijlstra wrote: > > On Mon, Jan 08, 2018 at 12:15:31PM -0800, Andi Kleen wrote: > >> diff --git a/arch/x86/include/asm/nospec-branch.h > >> b/arch/x86/include/asm/nospec-branch.h > >> index

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 15:56 -0800, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 3:44 PM, David Woodhouse wrote: > > > > To guard against this fill the return buffer with controlled > > content during context switch. This prevents any underflows. > > Ugh. I really dislike

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 15:56 -0800, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 3:44 PM, David Woodhouse wrote: > > > > To guard against this fill the return buffer with controlled > > content during context switch. This prevents any underflows. > > Ugh. I really dislike this patch. Everything

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 23:26 +0100, Peter Zijlstra wrote: > > > is because that might get interpreted as a "push %rip" and not go on > > the RSB at all. Hence the 'pause' between each one. > > OK, then make the comment say that. Fixed. I've also shifted the #ifdef CONFIG_RETPOLINE to the call

Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

On Mon, 2018-01-08 at 23:26 +0100, Peter Zijlstra wrote: > > > is because that might get interpreted as a "push %rip" and not go on > > the RSB at all. Hence the 'pause' between each one. > > OK, then make the comment say that. Fixed. I've also shifted the #ifdef CONFIG_RETPOLINE to the call

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Mon, 2018-01-08 at 18:42 +0100, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote: > > On 01/08/2018 08:14 AM, Peter Zijlstra wrote: > > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote: > > >>> a good suggestion, but we encountered some issues

Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Mon, 2018-01-08 at 18:42 +0100, Peter Zijlstra wrote: > On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote: > > On 01/08/2018 08:14 AM, Peter Zijlstra wrote: > > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote: > > >>> a good suggestion, but we encountered some issues

Re: [PATCH v6 10/10] x86/retpoline: Exclude objtool with retpoline

On Mon, 2018-01-08 at 11:25 +0100, Thomas Gleixner wrote: > On Sun, 7 Jan 2018, David Woodhouse wrote: > > Cc+ Josh Poimboeuf > > Sigh > > > From: Andi Kleen > >  > > objtool's assembler nanny currently cannot deal with the code generated > > by

Re: [PATCH v6 10/10] x86/retpoline: Exclude objtool with retpoline

On Mon, 2018-01-08 at 11:25 +0100, Thomas Gleixner wrote: > On Sun, 7 Jan 2018, David Woodhouse wrote: > > Cc+ Josh Poimboeuf > > Sigh > > > From: Andi Kleen > >  > > objtool's assembler nanny currently cannot deal with the code generated > > by the retpoline compiler and throws hundreds

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On Mon, 2018-01-08 at 11:08 +0100, Thomas Gleixner wrote: > I'm dropping these patches until this question is answered. I've rebased my retpoline tree on top of tip/x86/pti from before those patches (from my BUG_SPECTRE_Vx patch). smime.p7s Description: S/MIME cryptographic signature

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On Mon, 2018-01-08 at 11:08 +0100, Thomas Gleixner wrote: > I'm dropping these patches until this question is answered. I've rebased my retpoline tree on top of tip/x86/pti from before those patches (from my BUG_SPECTRE_Vx patch). smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Sun, 2018-01-07 at 23:06 -0600, Josh Poimboeuf wrote: > > Here's the use case I had in mind before.  With paravirt, > >   ENABLE_INTERRUPTS(CLBR_NONE) > > becomes > >   push  %rax >   call  *pv_irq_ops.irq_enable >   pop   %rax > > and I wanted to apply those instructions with an

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Sun, 2018-01-07 at 23:06 -0600, Josh Poimboeuf wrote: > > Here's the use case I had in mind before.  With paravirt, > >   ENABLE_INTERRUPTS(CLBR_NONE) > > becomes > >   push  %rax >   call  *pv_irq_ops.irq_enable >   pop   %rax > > and I wanted to apply those instructions with an

  1   2   3   >