Re: [Xen-devel] Linux 5.0 regression: BUG: unable to handle kernel paging request at ffff888023e26778

On 09/02/2019 18:54, Linus Torvalds wrote: > On Sat, Feb 9, 2019 at 12:24 AM Sander Eikelenboom > wrote: >> I haven't got a reproducer so i might be hard to hit it again, >> system is AMD and this is from the host kernel running under >> the Xen hypervisor might it matter. > I think this is a

Re: [PATCH v2 3/3] x86/umwait: Control umwait maximum time

On 17/01/2019 00:00, Andy Lutomirski wrote: > On Wed, Jan 16, 2019 at 1:24 PM Fenghua Yu wrote: >> IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC-quanta >> that processor can stay in C0.1 or C0.2. >> >> The maximum time value in IA32_UMWAIT_CONTROL[31-2] is set as zero which >>

Re: [Xen-devel] [PATCH -next] x86/xen: Fix read buffer overflow

On 18/12/2018 10:42, YueHaibing wrote: > On 2018/12/18 16:31, Juergen Gross wrote: >> On 18/12/2018 09:19, YueHaibing wrote: >>> Fix smatch warning: >>> >>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error: >>> buffer overflow 'early_idt_handler_array' 32 <= 32 >>> >>> Fixes: 42b3a4cb5609

Re: [Xen-devel] [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 06/12/2018 23:30, Paolo Bonzini wrote: > On 07/12/18 00:11, Boris Ostrovsky wrote: >> On 12/6/18 5:49 PM, Paolo Bonzini wrote: >>> On 06/12/18 23:34, Boris Ostrovsky wrote: On 12/6/18 5:11 PM, Paolo Bonzini wrote: > and also > > depends on !EFI > > because even

Re: [Xen-devel] [PATCH v2] xen: add new hypercall buffer mapping device

On 18/06/18 15:36, Juergen Gross wrote: > +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma) > +{ > + struct privcmd_buf_private *file_priv = file->private_data; > + struct privcmd_buf_vma_private *vma_priv; > + unsigned long count = vma_pages(vma); > +

Re: [Xen-devel] [PATCH v2] xen: add new hypercall buffer mapping device

On 18/06/18 15:36, Juergen Gross wrote: > +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma) > +{ > + struct privcmd_buf_private *file_priv = file->private_data; > + struct privcmd_buf_vma_private *vma_priv; > + unsigned long count = vma_pages(vma); > +

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

On 07/06/18 11:21, Paul Durrant wrote: > Commit 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") > introduced a static checker warning: > > drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource() > warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()' > 64

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

On 07/06/18 11:21, Paul Durrant wrote: > Commit 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") > introduced a static checker warning: > > drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource() > warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()' > 64

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On 09/05/18 11:21, Roger Pau Monne wrote: > On PVH MTRR is not initialized by the firmware (because there's no > firmware), so the kernel is started with MTRR disabled which means all > memory accesses are UC. > > So far there have been no issues (ie: slowdowns) caused by this > because PVH only

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On 09/05/18 11:21, Roger Pau Monne wrote: > On PVH MTRR is not initialized by the firmware (because there's no > firmware), so the kernel is started with MTRR disabled which means all > memory accesses are UC. > > So far there have been no issues (ie: slowdowns) caused by this > because PVH only

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 02/05/18 16:09, Jan Beulich wrote: On 02.05.18 at 17:08, wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >> On 02.05.18 at 16:57, wrote: On 05/02/2018 04:05 AM, Jan Beulich wrote: On 30.04.18 at 18:23,

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 02/05/18 16:09, Jan Beulich wrote: On 02.05.18 at 17:08, wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >> On 02.05.18 at 16:57, wrote: On 05/02/2018 04:05 AM, Jan Beulich wrote: On 30.04.18 at 18:23, wrote: >> Signed-off-by: Boris Ostrovsky >

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 23/03/18 14:27, Wanpeng Li wrote: > 2018-03-22 21:53 GMT+08:00 Andrew Cooper <andrew.coop...@citrix.com>: >> On 22/03/18 13:39, Wanpeng Li wrote: >>> 2018-03-22 20:38 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>: >>>> On 22/03/2018 12:04, Andrew Coope

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 23/03/18 14:27, Wanpeng Li wrote: > 2018-03-22 21:53 GMT+08:00 Andrew Cooper : >> On 22/03/18 13:39, Wanpeng Li wrote: >>> 2018-03-22 20:38 GMT+08:00 Paolo Bonzini : >>>> On 22/03/2018 12:04, Andrew Cooper wrote: >>>>> We've got a Force Em

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/18 13:39, Wanpeng Li wrote: > 2018-03-22 20:38 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>: >> On 22/03/2018 12:04, Andrew Cooper wrote: >>> We've got a Force Emulation Prefix (ud2a; .ascii "xen") for doing >>> magic. Originally, this w

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/18 13:39, Wanpeng Li wrote: > 2018-03-22 20:38 GMT+08:00 Paolo Bonzini : >> On 22/03/2018 12:04, Andrew Cooper wrote: >>> We've got a Force Emulation Prefix (ud2a; .ascii "xen") for doing >>> magic. Originally, this was used for PV guests to exp

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/2018 10:42, Paolo Bonzini wrote: > On 22/03/2018 11:19, Andrew Cooper wrote: >> On 22/03/2018 10:07, Paolo Bonzini wrote: >>> On 22/03/2018 09:34, Wanpeng Li wrote: >>>> From: Wanpeng Li <wanpen...@tencent.com> >>>> >>>> Exp

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/2018 10:42, Paolo Bonzini wrote: > On 22/03/2018 11:19, Andrew Cooper wrote: >> On 22/03/2018 10:07, Paolo Bonzini wrote: >>> On 22/03/2018 09:34, Wanpeng Li wrote: >>>> From: Wanpeng Li >>>> >>>> Explicit segment ove

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/2018 10:07, Paolo Bonzini wrote: > On 22/03/2018 09:34, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Explicit segment overides other than %fs and %gs are documented as ignored by >> both Intel and AMD. >> >> In practice, this means that: >> >> * Explicit uses of

Re: [PATCH] KVM: X86: Fix the decoding of segment overrides in 64bit mode

On 22/03/2018 10:07, Paolo Bonzini wrote: > On 22/03/2018 09:34, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Explicit segment overides other than %fs and %gs are documented as ignored by >> both Intel and AMD. >> >> In practice, this means that: >> >> * Explicit uses of %ss don't actually yield

Re: [PATCH] fix one dead link in ia64/xen.txt

On 20/03/18 19:56, Dongliang Mu wrote: > Signed-off-by: Dongliang Mu > --- > Documentation/ia64/xen.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/ia64/xen.txt b/Documentation/ia64/xen.txt > index

Re: [PATCH] fix one dead link in ia64/xen.txt

On 20/03/18 19:56, Dongliang Mu wrote: > Signed-off-by: Dongliang Mu > --- > Documentation/ia64/xen.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/ia64/xen.txt b/Documentation/ia64/xen.txt > index a12c74ce2773..464d4c29b8b5 100644 > ---

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:51, Nadav Amit wrote: > Andrew Cooper <andrew.coop...@citrix.com> wrote: > >> On 16/02/2018 00:25, Nadav Amit wrote: >>> Dave Hansen <dave.han...@linux.intel.com> wrote: >>> >>>> On 02/15/2018 08:35 AM, Nadav Amit wrote: >&

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:51, Nadav Amit wrote: > Andrew Cooper wrote: > >> On 16/02/2018 00:25, Nadav Amit wrote: >>> Dave Hansen wrote: >>> >>>> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>>>> I removed the PTI disabling while SMEP is unsupporte

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:25, Nadav Amit wrote: > Dave Hansen wrote: > >> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>> I removed the PTI disabling while SMEP is unsupported, although I >>> must admit I did not fully understand why it is required. >> Do you mean you don't

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:25, Nadav Amit wrote: > Dave Hansen wrote: > >> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>> I removed the PTI disabling while SMEP is unsupported, although I >>> must admit I did not fully understand why it is required. >> Do you mean you don't fully understand how PTI gives

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On 16/02/2018 00:08, Linus Torvalds wrote: > On Thu, Feb 15, 2018 at 3:29 PM, Andy Lutomirski wrote: >> Linus, how would you feel about, by default, preventing 64-bit >> programs from long-jumping to __USER32_CS and vice versa? > How? It's a standard GDT entry. Are you going to

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On 16/02/2018 00:08, Linus Torvalds wrote: > On Thu, Feb 15, 2018 at 3:29 PM, Andy Lutomirski wrote: >> Linus, how would you feel about, by default, preventing 64-bit >> programs from long-jumping to __USER32_CS and vice versa? > How? It's a standard GDT entry. Are you going to start switching

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/2018 21:09, Pavel Machek wrote: > On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote: >> PCID bit set in CPUID should print a big fat warning like "WARNING: >> you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your >> performance will increase dramatically if you switch to a 64-bit

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/2018 21:09, Pavel Machek wrote: > On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote: >> PCID bit set in CPUID should print a big fat warning like "WARNING: >> you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your >> performance will increase dramatically if you switch to a 64-bit

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/18 13:35, Joerg Roedel wrote: > Hi Juergen, > > On Fri, Feb 09, 2018 at 01:11:42PM +0100, Juergen Gross wrote: >> On 09/02/18 10:25, Joerg Roedel wrote: >>> XENPV is also untested from my side, but I added checks to >>> not do the stack switches in the entry-code when XENPV is >>>

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/18 13:35, Joerg Roedel wrote: > Hi Juergen, > > On Fri, Feb 09, 2018 at 01:11:42PM +0100, Juergen Gross wrote: >> On 09/02/18 10:25, Joerg Roedel wrote: >>> XENPV is also untested from my side, but I added checks to >>> not do the stack switches in the entry-code when XENPV is >>>

Re: [Xen-devel] [PATCH] [v2] xen: hypercall: fix out-of-bounds memcpy

On 05/02/18 15:03, Arnd Bergmann wrote: Snipping deleted code to make things clearer: > + if (cmd > ARRAY_SIZE(physdevop_len)) > + return -ENOSYS; > > + len = physdevop_len[cmd]; > + memcpy(, arg, len); You'll want an array_nospec() or whatever its called these days. 

Re: [Xen-devel] [PATCH] [v2] xen: hypercall: fix out-of-bounds memcpy

On 05/02/18 15:03, Arnd Bergmann wrote: Snipping deleted code to make things clearer: > + if (cmd > ARRAY_SIZE(physdevop_len)) > + return -ENOSYS; > > + len = physdevop_len[cmd]; > + memcpy(, arg, len); You'll want an array_nospec() or whatever its called these days. 

Re: [PATCH] x86/xen: init %gs very early to avoid page faults with stack protector

On 01/02/18 12:16, Juergen Gross wrote: > When running as Xen pv guest %gs is initialized some time after > C code is started. Depending on stack protector usage this might be > too late, resulting in page faults. > > So setup %gs and MSR_GS_BASE in assembly code already. > > Cc:

Re: [PATCH] x86/xen: init %gs very early to avoid page faults with stack protector

On 01/02/18 12:16, Juergen Gross wrote: > When running as Xen pv guest %gs is initialized some time after > C code is started. Depending on stack protector usage this might be > too late, resulting in page faults. > > So setup %gs and MSR_GS_BASE in assembly code already. > > Cc:

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

On 23/01/18 18:45, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 + > David Woodhouse wrote: > >> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO >> bit set, they don't need KPTI either. > This is starting to get messy because we will eventually

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

On 23/01/18 18:45, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 + > David Woodhouse wrote: > >> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO >> bit set, they don't need KPTI either. > This is starting to get messy because we will eventually need to integrate > >

Re: [PATCH v2 2/8] x86/cpufeatures: Add AMD feature bits for Prediction Command

On 22/01/18 14:31, Tom Lendacky wrote: > On 1/21/2018 12:01 PM, Andrew Cooper wrote: >> On 21/01/18 17:50, Tom Lendacky wrote: >>> On 1/21/2018 3:49 AM, David Woodhouse wrote: >>>> AMD doesn't implement the Speculation Control MSR that Intel does, but >>>

Re: [PATCH v2 2/8] x86/cpufeatures: Add AMD feature bits for Prediction Command

On 22/01/18 14:31, Tom Lendacky wrote: > On 1/21/2018 12:01 PM, Andrew Cooper wrote: >> On 21/01/18 17:50, Tom Lendacky wrote: >>> On 1/21/2018 3:49 AM, David Woodhouse wrote: >>>> AMD doesn't implement the Speculation Control MSR that Intel does, but >>>

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

On 21/01/2018 20:04, David Woodhouse wrote: > On Sun, 2018-01-21 at 19:37 +0000, Andrew Cooper wrote: >> It doesn't matter if an attacker can use SP1 to try and skip the IBPB. >> >> Exits to userspace/guest are serialising (with some retroactive updates >> to the ar

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

On 21/01/2018 20:04, David Woodhouse wrote: > On Sun, 2018-01-21 at 19:37 +0000, Andrew Cooper wrote: >> It doesn't matter if an attacker can use SP1 to try and skip the IBPB. >> >> Exits to userspace/guest are serialising (with some retroactive updates >> to the ar

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

On 21/01/18 19:31, David Woodhouse wrote: > On Sun, 2018-01-21 at 20:01 +0100, Borislav Petkov wrote: >> so execution runs directly into the MSR write and the JMP is gone. >> >> So I don't see indirect branches anywhere... > Wait until the wind changes. > > Congratulations, you've just turned a

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

On 21/01/18 19:31, David Woodhouse wrote: > On Sun, 2018-01-21 at 20:01 +0100, Borislav Petkov wrote: >> so execution runs directly into the MSR write and the JMP is gone. >> >> So I don't see indirect branches anywhere... > Wait until the wind changes. > > Congratulations, you've just turned a

Re: [PATCH v2 2/8] x86/cpufeatures: Add AMD feature bits for Prediction Command

On 21/01/18 17:50, Tom Lendacky wrote: > On 1/21/2018 3:49 AM, David Woodhouse wrote: >> AMD doesn't implement the Speculation Control MSR that Intel does, but >> the Prediction Control MSR does exist and is advertised by a separate >> CPUID bit. Add support for that. >> >> Signed-off-by: David

Re: [PATCH v2 2/8] x86/cpufeatures: Add AMD feature bits for Prediction Command

On 21/01/18 17:50, Tom Lendacky wrote: > On 1/21/2018 3:49 AM, David Woodhouse wrote: >> AMD doesn't implement the Speculation Control MSR that Intel does, but >> the Prediction Control MSR does exist and is advertised by a separate >> CPUID bit. Add support for that. >> >> Signed-off-by: David

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 18/01/2018 23:25, Andy Lutomirski wrote: > On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli > wrote: >> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: >>> On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: On 18/01/2018 18:08, Dave

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 18/01/2018 23:25, Andy Lutomirski wrote: > On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli > wrote: >> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: >>> On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: On 18/01/2018 18:08, Dave Hansen wrote: > On

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On 17/01/18 09:02, Joerg Roedel wrote: > Hi Boris, > > thanks for testing this :) > > On Tue, Jan 16, 2018 at 09:47:06PM -0500, Boris Ostrovsky wrote: >> On 01/16/2018 11:36 AM, Joerg Roedel wrote: >>> +.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0 >> >> This (and next patch's

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On 17/01/18 09:02, Joerg Roedel wrote: > Hi Boris, > > thanks for testing this :) > > On Tue, Jan 16, 2018 at 09:47:06PM -0500, Boris Ostrovsky wrote: >> On 01/16/2018 11:36 AM, Joerg Roedel wrote: >>> +.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0 >> >> This (and next patch's

Re: [RFC PATCH 00/16] PTI support for x86-32

On 16/01/18 18:59, Linus Torvalds wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: >> One of the things that are surely broken is XEN_PV support. >> I'd appreciate any help with testing and bugfixing on that >> front. > Xen PV and PTI don't work together even on

Re: [RFC PATCH 00/16] PTI support for x86-32

On 16/01/18 18:59, Linus Torvalds wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: >> One of the things that are surely broken is XEN_PV support. >> I'd appreciate any help with testing and bugfixing on that >> front. > Xen PV and PTI don't work together even on x86-64 afaik, the Xen

Re: Improve retpoline for Skylake

On 15/01/18 16:57, Andy Lutomirski wrote: > >> On Jan 15, 2018, at 12:26 AM, Jon Masters wrote: >> >>> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: >>> On Fri, 12 Jan 2018, Andi Kleen wrote: > Skylake still loses if it takes an SMI, right? SMMs are

Re: Improve retpoline for Skylake

On 15/01/18 16:57, Andy Lutomirski wrote: > >> On Jan 15, 2018, at 12:26 AM, Jon Masters wrote: >> >>> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: >>> On Fri, 12 Jan 2018, Andi Kleen wrote: > Skylake still loses if it takes an SMI, right? SMMs are usually rare, especially

Re: [PATCH] x86/retpoline: Fill RSB on context switch for affected CPUs

On 12/01/18 17:49, David Woodhouse wrote: > When we context switch from a shallow call stack to a deeper one, as we > 'ret' up the deeper side we may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. This is > problematic if we have neither SMEP

Re: [PATCH] x86/retpoline: Fill RSB on context switch for affected CPUs

On 12/01/18 17:49, David Woodhouse wrote: > When we context switch from a shallow call stack to a deeper one, as we > 'ret' up the deeper side we may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. This is > problematic if we have neither SMEP

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

On 09/01/2018 00:58, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen wrote: >> Essentially the RSB are hidden registers, and the only way to clear them >> is the FILL_RETURN_BUFFER sequence. I don't see how clearing anything else >> would help? > Forget

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

On 09/01/2018 00:58, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen wrote: >> Essentially the RSB are hidden registers, and the only way to clear them >> is the FILL_RETURN_BUFFER sequence. I don't see how clearing anything else >> would help? > Forget theory. Look at

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

On 08/01/18 14:47, Tom Lendacky wrote: > On 1/8/2018 5:10 AM, Thomas Gleixner wrote: >> On Mon, 8 Jan 2018, Andrew Cooper wrote: >> >>> On 08/01/18 10:08, Thomas Gleixner wrote: >>>> On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: >>>> >>&g

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

On 08/01/18 14:47, Tom Lendacky wrote: > On 1/8/2018 5:10 AM, Thomas Gleixner wrote: >> On Mon, 8 Jan 2018, Andrew Cooper wrote: >> >>> On 08/01/18 10:08, Thomas Gleixner wrote: >>>> On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: >>>> >>&g

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

On 08/01/18 10:42, Paul Turner wrote: > A sequence for efficiently refilling the RSB is: > mov $8, %rax; > .align 16; >3: call 4f; > 3p: pause; call 3p; > .align 16; > 4: call 5f; > 4p: pause; call 4p; > .align 16; >5: dec %rax; > jnz 3b; > add $(16*8),

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

On 08/01/18 10:42, Paul Turner wrote: > A sequence for efficiently refilling the RSB is: > mov $8, %rax; > .align 16; >3: call 4f; > 3p: pause; call 3p; > .align 16; > 4: call 5f; > 4p: pause; call 4p; > .align 16; >5: dec %rax; > jnz 3b; > add $(16*8),

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

On 08/01/18 10:08, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: > >> Commit-ID: 0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Gitweb: >> https://git.kernel.org/tip/0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Author: Tom Lendacky >>

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

On 08/01/18 10:08, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: > >> Commit-ID: 0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Gitweb: >> https://git.kernel.org/tip/0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Author: Tom Lendacky >> AuthorDate: Fri, 5 Jan

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 21:23, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Andrew Cooper wrote: >> On 06/01/18 11:49, David Woodhouse wrote: >>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>> index 372ba3f..40e6e54 100644 >>> --- a/arch/x86/ke

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 21:23, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Andrew Cooper wrote: >> On 06/01/18 11:49, David Woodhouse wrote: >>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>> index 372ba3f..40e6e54 100644 >>> --- a/arch/x86/ke

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 11:49, David Woodhouse wrote: > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 372ba3f..40e6e54 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -904,6 +904,11 @@ static void __init early_identify_cpu(struct

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 11:49, David Woodhouse wrote: > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 372ba3f..40e6e54 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -904,6 +904,11 @@ static void __init early_identify_cpu(struct

Re: Avoid speculative indirect calls in kernel

On 04/01/2018 23:47, Tom Lendacky wrote: > On 1/4/2018 2:05 PM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: >>> Yes, lfence is sufficient.  As long as the target is in the register >>> before the lfence and we jump through the register all is good, i.e.: >>

Re: Avoid speculative indirect calls in kernel

On 04/01/2018 23:47, Tom Lendacky wrote: > On 1/4/2018 2:05 PM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: >>> Yes, lfence is sufficient.  As long as the target is in the register >>> before the lfence and we jump through the register all is good, i.e.: >>

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 04/01/18 20:05, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: >> From: David Woodhouse >> >> We are impervious to the indirect branch prediction attack with retpoline >> but firmware won't be, so we still need to set IBRS to protect >> firmware

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 04/01/18 20:05, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: >> From: David Woodhouse >> >> We are impervious to the indirect branch prediction attack with retpoline >> but firmware won't be, so we still need to set IBRS to protect >> firmware code execution when

Re: [PATCH 0/7] IBRS patch series

On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up

Re: [PATCH 0/7] IBRS patch series

On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up vulnerable. > That

Re: Avoid speculative indirect calls in kernel

On 04/01/18 15:32, Paolo Bonzini wrote: > On 04/01/2018 16:29, Woodhouse, David wrote: >> Adding that for KVM is in the Linux IBRS patch set that I've seen. >> Didn't we already have a conversation about how the Linux patch set >> does it as an atomically-switched MSR while you've done it manually

Re: Avoid speculative indirect calls in kernel

On 04/01/18 15:32, Paolo Bonzini wrote: > On 04/01/2018 16:29, Woodhouse, David wrote: >> Adding that for KVM is in the Linux IBRS patch set that I've seen. >> Didn't we already have a conversation about how the Linux patch set >> does it as an atomically-switched MSR while you've done it manually

Re: [PATCH v3 10/13] x86/retpoline/pvops: Convert assembler indirect jumps

On 04/01/18 15:02, Juergen Gross wrote: > On 04/01/18 15:37, David Woodhouse wrote: >> Convert pvops invocations to use non-speculative call sequences, when >> CONFIG_RETPOLINE is enabled. >> >> There is scope for future optimisation here — once the pvops methods are >> actually set, we could just

Re: [PATCH v3 10/13] x86/retpoline/pvops: Convert assembler indirect jumps

On 04/01/18 15:02, Juergen Gross wrote: > On 04/01/18 15:37, David Woodhouse wrote: >> Convert pvops invocations to use non-speculative call sequences, when >> CONFIG_RETPOLINE is enabled. >> >> There is scope for future optimisation here — once the pvops methods are >> actually set, we could just

Re: Avoid speculative indirect calls in kernel

On 04/01/18 14:20, Paolo Bonzini wrote: > On 04/01/2018 12:47, Woodhouse, David wrote: >> On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote: No, really. The full mitigation with the microcode update and IBRS support is *slow*. Horribly slow. >>> What is IBRS? Invalidate BRanch

Re: Avoid speculative indirect calls in kernel

On 04/01/18 14:20, Paolo Bonzini wrote: > On 04/01/2018 12:47, Woodhouse, David wrote: >> On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote: No, really. The full mitigation with the microcode update and IBRS support is *slow*. Horribly slow. >>> What is IBRS? Invalidate BRanch

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

On 02/01/18 14:24, Juergen Gross wrote: > On 02/01/18 15:18, Boris Ostrovsky wrote: >> On 12/23/2017 09:50 PM, Nick Desaulniers wrote: >>> The header declares this function as __init but is defined in __ref >>> section. >>> >>> Signed-off-by: Nick Desaulniers >> AFAIK

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

On 02/01/18 14:24, Juergen Gross wrote: > On 02/01/18 15:18, Boris Ostrovsky wrote: >> On 12/23/2017 09:50 PM, Nick Desaulniers wrote: >>> The header declares this function as __init but is defined in __ref >>> section. >>> >>> Signed-off-by: Nick Desaulniers >> AFAIK section attributes in header

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/17 14:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> On 29/11/2017 15:25, Boris Ostrovsky wrote: >> zeropage is x86/Linux-specific so we'd need some sort of firmware (like >> grub) between a hypervisor and Linux to convert hvm_start_info to >>

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/17 14:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> On 29/11/2017 15:25, Boris Ostrovsky wrote: >> zeropage is x86/Linux-specific so we'd need some sort of firmware (like >> grub) between a hypervisor and Linux to convert hvm_start_info to >>

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/11/17 19:34, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/11/17 19:34, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 20:29, Sander Eikelenboom wrote: > On 26/10/17 19:49, Craig Bergstrom wrote: >> Sander, thanks for the details, they've been very useful. >> >> I suspect that your host system's mem=2048M parameter is causing the >> problem. Any chance you can confirm by removing the parameter and >>

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 20:29, Sander Eikelenboom wrote: > On 26/10/17 19:49, Craig Bergstrom wrote: >> Sander, thanks for the details, they've been very useful. >> >> I suspect that your host system's mem=2048M parameter is causing the >> problem. Any chance you can confirm by removing the parameter and >>

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: #ifdef CONFIG_PARAVIRT +/* + * Paravirt alternatives are applied much earlier than normal alternatives. + * They

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: #ifdef CONFIG_PARAVIRT +/* + * Paravirt alternatives are applied much earlier than normal alternatives. + * They

Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping

On 27/09/17 15:56, Juergen Gross wrote: > On 27/09/17 16:48, Boris Ostrovsky wrote: >> On 09/27/2017 10:33 AM, Juergen Gross wrote: >>> On 27/09/17 15:38, Boris Ostrovsky wrote: On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a

Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping

On 27/09/17 15:56, Juergen Gross wrote: > On 27/09/17 16:48, Boris Ostrovsky wrote: >> On 09/27/2017 10:33 AM, Juergen Gross wrote: >>> On 27/09/17 15:38, Boris Ostrovsky wrote: On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a

Re: [Xen-devel] [PATCH] xen: support 52 bit physical addresses in pv guests

On 21/09/17 17:00, Boris Ostrovsky wrote: Signed-off-by: Juergen Gross ---    arch/x86/include/asm/xen/page.h | 11 ++-    arch/x86/xen/mmu_pv.c   |  4 ++--    2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h

Re: [Xen-devel] [PATCH] xen: support 52 bit physical addresses in pv guests

On 21/09/17 17:00, Boris Ostrovsky wrote: Signed-off-by: Juergen Gross ---    arch/x86/include/asm/xen/page.h | 11 ++-    arch/x86/xen/mmu_pv.c   |  4 ++--    2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h

Re: [RFC 17/17] x86/traps: Use a new on_thread_stack() helper to clean up an assertion

On 12/09/2017 21:11, Josh Poimboeuf wrote: > On Wed, Sep 06, 2017 at 02:37:02PM -0700, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/include/asm/processor.h | 17 + >> arch/x86/include/asm/thread_info.h | 11 --- >>

Re: [RFC 17/17] x86/traps: Use a new on_thread_stack() helper to clean up an assertion

On 12/09/2017 21:11, Josh Poimboeuf wrote: > On Wed, Sep 06, 2017 at 02:37:02PM -0700, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/include/asm/processor.h | 17 + >> arch/x86/include/asm/thread_info.h | 11 --- >> arch/x86/kernel/traps.c

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

On 08/09/17 15:48, Juergen Gross wrote: > static void gnttab_request_version(void) > { > - int rc; > + long rc; > struct gnttab_set_version gsv; > > - gsv.version = 1; > + rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); This hypercall is information leak and

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

On 08/09/17 15:48, Juergen Gross wrote: > static void gnttab_request_version(void) > { > - int rc; > + long rc; > struct gnttab_set_version gsv; > > - gsv.version = 1; > + rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); This hypercall is information leak and

Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header

On 04/09/17 13:41, Jan Beulich wrote: On 04.09.17 at 12:35, wrote: >> On 04/09/17 11:15, Jan Beulich wrote: >> On 04.09.17 at 10:17, wrote: On 03/09/17 10:38, Nicolas Iooss wrote: > Commit d162809f85b4 ("xen/x86: Do not call

Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header

On 04/09/17 13:41, Jan Beulich wrote: On 04.09.17 at 12:35, wrote: >> On 04/09/17 11:15, Jan Beulich wrote: >> On 04.09.17 at 10:17, wrote: On 03/09/17 10:38, Nicolas Iooss wrote: > Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until > shared_info is

<    1   2   3   4   5   6   >