similar to: [PATCH 1/4, RFC] x86_64: basic changes for supporting compatibility mode guest (version 2)

Jan, any reason why this patch isn't in Linus's tree already, and why it wasn't marked for inclusion in a -stable kernel release? thanks, greg k-h On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote: > This fixes CVE-2013-0228 / XSA-42 > > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user > in 32bit PV guest can use to crash the

Jan, any reason why this patch isn't in Linus's tree already, and why it wasn't marked for inclusion in a -stable kernel release? thanks, greg k-h On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote: > This fixes CVE-2013-0228 / XSA-42 > > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user > in 32bit PV guest can use to crash the

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,

Both the APM BIOS and PnP BIOS code use a segment hack to simulate real mode selector 0x40 (which points to the BIOS data area at 0x00400 in real mode). Several broken BIOSen use selector 0x40 as if they were running in real mode, which we make work by faking up selector 0x40 in the GDT to point to physical memory starting at 0x400. We limit the access to the remainder of this physical page

Both the APM BIOS and PnP BIOS code use a segment hack to simulate real mode selector 0x40 (which points to the BIOS data area at 0x00400 in real mode). Several broken BIOSen use selector 0x40 as if they were running in real mode, which we make work by faking up selector 0x40 in the GDT to point to physical memory starting at 0x400. We limit the access to the remainder of this physical page

On Thu, 17 Jan 2013 22:22:47 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Jan had some comments about that patch: > > https://patchwork.kernel.org/patch/1745041/ > > Please fix it up so I can put it in the Linux tree. Please see below. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Thanks, Mukesh diff --git a/arch/x86/xen/xen-head.S

Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well") reworked the iopl syscall to use I/O bitmaps. Unfortunately this broke Xen PV domains using that syscall as there is currently no I/O bitmap support in PV domains. Add I/O bitmap support via a new paravirt function update_io_bitmap which Xen PV domains can use to update their I/O bitmaps via a

Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well") reworked the iopl syscall to use I/O bitmaps. Unfortunately this broke Xen PV domains using that syscall as there is currently no I/O bitmap support in PV domains. Add I/O bitmap support via a new paravirt function update_io_bitmap which Xen PV domains can use to update their I/O bitmaps via a

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains.

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains.

1: correct LDT checks 2: add address validity check to guest_map_l1e() 3: use {rd,wr}{fs,gs}base when available 4: check for canonical address before doing page walks Signed-off-by: Jan Beulich <jbeulich@suse.com>

I discovered an even more subtle problem; the PnP BIOS code is saving the %fs and %gs segments in inline assembler, yet it also uses the same hack for patching in a fake real mode selector for the BIOS data area. Note that the protected mode selector 0x40 overlaps the user TLS area in the GDT; this means that badly timed PnP BIOS calls could come in, save %fs, come back, and restore %fs -- to

I discovered an even more subtle problem; the PnP BIOS code is saving the %fs and %gs segments in inline assembler, yet it also uses the same hack for patching in a fake real mode selector for the BIOS data area. Note that the protected mode selector 0x40 overlaps the user TLS area in the GDT; this means that badly timed PnP BIOS calls could come in, save %fs, come back, and restore %fs -- to

flight 13383 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 16 guest-start fail REGR. vs. 13379 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 12

flight 9061 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9061/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9054 test-i386-i386-pv

This applies to both SVM and VMX. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -310,7 +310,7 @@ static struct keyhandler vmcb_dump_keyha .desc = "dump AMD-V VMCBs" }; -void setup_vmcb_dump(void) +void __init setup_vmcb_dump(void) { register_keyhandler(''v'',

During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn''t passed back correctly. While this is benign in most cases (as the value isn''t being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan

These are known to not support the feature, so we can save ourselves from emitting the resulting #GP fault recovery related message (which might worry people looking at the logs). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -204,7 +204,7 @@ static void __devinit init_intel(struct detect_ht(c); } - if

Those two should always be delivered first imo. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i struct hvm_domain *plat = &v->domain->arch.hvm_domain; int vector; - if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector) -

... rather than __assign_irq_vector(), to ensure desc->affinity gets initialized properly. This at once eliminates the need to forward-declare the latter function. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -25,7 +25,6 @@ #include <public/physdev.h> static void parse_irq_vector_map_param(char *s); -static int