similar to: Xen Security Advisory 44 (CVE-2013-1917) - Xen PV DoS vulnerability with SYSENTER

I implemented sysenter for 32-on-64, since it seemed straightforward enough. It mostly works, but every now and again I get vcpus just hanging in blocked state, as if events are being lost or ignored. Its very similar to the symptoms that other people have reported against the pvops kernel, which I have not managed to reproduce. Perhaps using sysenter is exacerbating an existing bug...

In compat mode, the return value here was uninitialized. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1fda49a076ed arch/i386/kernel/sysenter.c --- a/arch/i386/kernel/sysenter.c Fri Apr 06 14:25:09 2007 -0700 +++ b/arch/i386/kernel/sysenter.c Fri Apr 06 14:27:31 2007 -0700 @@ -254,7 +254,7 @@ int arch_setup_additional_pages(struct l { struct mm_struct *mm = current->mm;

In compat mode, the return value here was uninitialized. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1fda49a076ed arch/i386/kernel/sysenter.c --- a/arch/i386/kernel/sysenter.c Fri Apr 06 14:25:09 2007 -0700 +++ b/arch/i386/kernel/sysenter.c Fri Apr 06 14:27:31 2007 -0700 @@ -254,7 +254,7 @@ int arch_setup_additional_pages(struct l { struct mm_struct *mm = current->mm;

The SYSENTER instruction jumps to a pre-programmed address at privilege level 0. We must not allow execution of guest code at that privilege level, so disable sysenter when we enter the guest (and re-enable it on return). This fixes current case where guest userspace can crash host. This save/restore adds 3% to guest context switch times. (If only there were some kind of scheduler hook or

The SYSENTER instruction jumps to a pre-programmed address at privilege level 0. We must not allow execution of guest code at that privilege level, so disable sysenter when we enter the guest (and re-enable it on return). This fixes current case where guest userspace can crash host. This save/restore adds 3% to guest context switch times. (If only there were some kind of scheduler hook or

This was set to zero immediately before the #GP injection code, since SYSENTER doesn''t really have a return address. Reported-by: Ian Campbell <Ian.Campbell@citrix.com> Furthermore, UREGS_cs and UREGS_rip don''t need to be written a second time, as the PUSHes above already can/do take care of putting in place the intended values. Signed-off-by: Jan Beulich

>>However, in case (2) the i386 guest kernel unconditionally goes for >>sysenter, and the hypervisor will accept this because CPUID has advertised >>SEP. *But* AMD CPUs do not support sysenter except in legacy mode! The >>correct thing to do is to use syscall. The hypervisor 32-on-64 compat code >>would accept CALLBACKTYPE_syscall, but the Linux i386 code here

.. for both 32-bit apps in 64-bit pv guests and 32on64. This patch depends on more than just guest_context saved/restored as guest state during save/restore/migrate (namely the new fields holding callback addresses). Since the 32-bit kernel doesn''t make use of syscall (it would be possible to do so now, when running on a 64-bit hv), the compat mode guest code path for syscall

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

The attached patch fixes the save/restore issue seen with 32bit Windows guest VMs. The root cause is that current Xen doesn''t intercept SYSENTER-related MSRs for 32bit guest VMs. As a result, the guest_sysenter_xxx fields contain incorrect values and shouldn''t be used for save/restore. This patch checks the LMA bit of EFER register in the save/restore code path. Please apply it

On Mon, 2007-03-05 at 13:06 +0100, Ingo Molnar wrote: > Subject: [patch] paravirt: VDSO page is essential > From: Ingo Molnar <mingo@elte.hu> > > commit 3bbf54725467d604698721384d858b5983b87e8f disables the VDSO for > CONFIG_PARAVIRT kernels. This #ifdeffery was a bad change: the VDSO is > an essential component of Linux, and this change forces all of them to > use

On Mon, 2007-03-05 at 13:06 +0100, Ingo Molnar wrote: > Subject: [patch] paravirt: VDSO page is essential > From: Ingo Molnar <mingo@elte.hu> > > commit 3bbf54725467d604698721384d858b5983b87e8f disables the VDSO for > CONFIG_PARAVIRT kernels. This #ifdeffery was a bad change: the VDSO is > an essential component of Linux, and this change forces all of them to > use

Paravirt-ops guests which move the fixmap also end up moving the syscall = VDSO. This fails if it is prelinked at a fixed address, which is why = COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN). = Several options are available to try to address this. Jan had cooked up = a patch for Xen that used build magic to find the parts of the VDSO that = need relocation. I

Paravirt-ops guests which move the fixmap also end up moving the syscall = VDSO. This fails if it is prelinked at a fixed address, which is why = COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN). = Several options are available to try to address this. Jan had cooked up = a patch for Xen that used build magic to find the parts of the VDSO that = need relocation. I

On 23/06/2020 14:03, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote: >> On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote: >>> If SNP is the sole reason #VC needs to be IST, then I'd strongly urge >>> you to only make it IST if/when you try and make SNP happen, not before. >> It is not the only reason, when ES

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the