search for: create_bounce_frame

Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"): > On Thu, May 04, 2017 at 05:06:07PM +0100, Ian Jackson wrote: > > I have fixed these in stretch but the jessie package remains unfixed. > > I think I may be able to find some backports somewhere. Would that be > > useful ? Is anyone else working on this ? > >

...debian/patches/series +++ b/debian/patches/series @@ -110,3 +110,6 @@ CVE-2016-9382-xsa192-4.5.patch CVE-2016-9385-xsa193-4.5.patch CVE-2016-9383-xsa195.patch CVE-2016-9379_CVE-2016-9380-xsa198.patch +multicall-deal-with-early-exit-condition +x86-discard-type-information-when-steali +x86-correct-create_bounce_frame diff --git a/debian/patches/x86-correct-create_bounce_frame b/debian/patches/x86-correct-create_bounce_frame new file mode 100644 index 0000000000..a3d6de2056 --- /dev/null +++ b/debian/patches/x86-correct-create_bounce_frame @@ -0,0 +1,41 @@ +From: Jan Beulich <jbeulich at suse.com> +Date: T...

...RDTSCP % 32, &d); } else @@ -2026,6 +2031,13 @@ asmlinkage int do_debug(struct cpu_user_ if ( !guest_mode(regs) ) { +#ifdef __x86_64__ + /* + * Single stepping across sysenter must not result in the single step + * flag being lost: record it here for create_bounce_frame to pick up. + */ + v->arch.eflags_mask |= (regs->eflags & EF_TF); +#endif /* Clear TF just for absolute sanity. */ regs->eflags &= ~EF_TF; /* Index: 2007-08-08/xen/arch/x86/x86_32/traps.c ====================================================...

...7) enter handle_19: (d7) NULL (d7) Booting from Hard Disk... (d7) Booting from 0000:7c00 (XEN) d8v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from 0000000000000028: (XEN) L4[0x000] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S: fault at ffff82d08022a472 create_bounce_frame+0x12b/0x13a (XEN) Domain 8 (vcpu#0) crashed on cpu#6: (XEN) ----[ Xen-4.6.6-9.el7 x86_64 debug=n Not tainted ]---- (XEN) CPU: 6 (XEN) RIP: e033:[<ffffffff8103f261>] (XEN) RFLAGS: 0000000000000292 EM: 1 CONTEXT: pv guest (d8v0) (XEN) rax: 0000000000000000 rbx: ffffffff81e05720 rcx: 00000000000...

...three times to switch input to Xen) (XEN) Freed 468kB init memory (XEN) d0v0 Unhandled page fault fault/trap [#14, ec=0002] (XEN) Pagetable walk from fffffbfff0480fbe: (XEN) L4[0x1f7] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S: fault at ffff82d080348a06 entry.o#create_bounce_frame+0x135/0x15f (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.9.2 x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e033:[<ffffffff82b9f731>] (XEN) RFLAGS: 0000000000000296 EM: 1 CONTEXT: pv guest (d0v0) (XEN) rax: fffffbfff0480fbe rbx: 0000000000000000 rcx:...

Hello, I''ve got several kernel panic on a domU under network activity (multiple rsync using rsh). I didn''t manage to reproduce it manually, but it happened 5times during the last month. Each time, it is the same kernel trace. I am using Debian 5.0.8 with kernel/hypervisor : ii linux-image-2.6.32-bpo.5-amd64 2.6.32-30~bpo50+1 Linux 2.6.32 for 64-bit PCs ii

Hello, I''ve got several kernel panic on a domU under network activity (multiple rsync using rsh). I didn''t manage to reproduce it manually, but it happened 5times during the last month. Each time, it is the same kernel trace. I am using Debian 5.0.8 with kernel/hypervisor : ii linux-image-2.6.32-bpo.5-amd64 2.6.32-30~bpo50+1 Linux 2.6.32 for 64-bit PCs ii

...ut to Xen) > (XEN) Freed 468kB init memory > (XEN) d0v0 Unhandled page fault fault/trap [#14, ec=0002] > (XEN) Pagetable walk from fffffbfff0480fbe: > (XEN) L4[0x1f7] = 0000000000000000 ffffffffffffffff > (XEN) domain_crash_sync called from entry.S: fault at ffff82d080348a06 entry.o#create_bounce_frame+0x135/0x15f > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-4.9.2 x86_64 debug=n Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e033:[<ffffffff82b9f731>] > (XEN) RFLAGS: 0000000000000296 EM: 1 CONTEXT: pv guest (d0v0) > (XEN) rax: fffffbfff0480fbe...

Replicated on another Xen node, CentOS 6.9 running Xen-4.6.6-8.el6. xl dmesg: (XEN) d38v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from 0000000000000028: (XEN) L4[0x000] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S: fault at ffff82d080230983 create_bounce_frame+0x12b/0x13a (XEN) Domain 38 (vcpu#0) crashed on cpu#2: (XEN) ----[ Xen-4.6.6-8.el6 x86_64 debug=n Not tainted ]---- (XEN) CPU: 2 (XEN) RIP: e033:[<ffffffff8103f261>] (XEN) RFLAGS: 0000000000000292 EM: 1 CONTEXT: pv guest (d38v0) (XEN) rax: 0000000000000000 rbx: ffffffff81e05720 rcx: 000000000...

Hi, I implemented my own Hypercall in xen. Now I wish my application under dom0 could talk to Xen via my hypercall. Currently, I make a stub in dom0''s kernel, which works as a proxy to forward the request. So, my application first makes a system call to dom0, which then makes hypercall to xen. Is this design necessary? May I call hypercalls from user application under dom0 directly?

From: Jason Gunthorpe <jgg at mellanox.com> gntdev simply wants to monitor a specific VMA for any notifier events, this can be done straightforwardly using mmu_range_notifier_insert() over the VMA's VA range. The notifier should be attached until the original VMA is destroyed. It is unclear if any of this is even sane, but at least a lot of duplicate code is removed. Cc: Oleksandr

Good morning, I am new to Xen, and trying to understand how Xen works. I have some questions about virtualization of interrupts on Xen. Thanks in advance for all helps. 1) From papers about Xen architecture found at Xen homepage, Xen seemingly intercepts interrupts of Dom1 (paravirtualization). So interrupts occur in Dom1''s context are sent to Xen, and Xen handles them. Is that correct?

(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.