Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
>>> On 21.09.16 at 16:18, wrote: > I have found the problem (after hours and hours of gruesome > debugging with the almighty print) and it seems that this could potentially > have quite a bit of impact if altp2m is enabled for a guest domain (even if > the > functionality is never actively used), since destroying any vcpu of this > guest could lead to a hypervisor panic. > So a malicious user could simply destroy and restart his VM(s) in order to > DOS the VMs of other users by killing the hypervisor. > Granted, this is not very effective, but, depending on the environment, it > is extremely easy to implement. So this is not a security problem because altp2m isn't a supported feature yet, albeit the features page doesn't explicitly state this one way or the other. The correct way to report a suspected security issue would, however, have been to contact secur...@xenproject.org (see also https://www.xenproject.org/security-policy.html). > The bug persists in Xen 4.7 and I do not that it was fixed in the current > master branch. > > The following happens. > The call > void hvm_vcpu_destroy(struct vcpu *v) > { > hvm_all_ioreq_servers_remove_vcpu(v->domain, v); > if ( hvm_altp2m_supported() ) > altp2m_vcpu_destroy(v); > > at some time reaches vmx_vcpu_update_eptp which ends with a > vmx_vmcs_exit(v);. I don't see how this can be a problem - it is properly paired with a vmx_vmcs_enter(). > For the next function in hvm_vcpu_destroy, the nestedhvm_vcpu_destroy(v) the > missing vmcs is no problem (at least in our use case), but the > free_compat_arg_xlat crashes. > The callstack is as follows: > hvm_vcpu_destroy > free_compat_arg_xlat > destroy_perdomain_mapping > map_domain_page > (probably inlined) mapcache_current_vcpu > sync_local_execstate For you to get here, you must be running on the idle vCPU, yet proof of this is not visible from the partial call stack you provide. And anyway, things breaking here suggest something going wrong earlier, or else - afaict - we'd run into this problem also without use of altp2m (basically whenever map_domain_page() would get used on the guest cleanup path, which - as you see from the call tree - happens always). So I'm afraid the patch you've put together is papering over a problem rather than fixing it, and the actual bug remains non-understood. Perhaps a relevant aspect is you saying "some time reaches vmx_vcpu_update_eptp": Why only sometimes? Afaics altp2m_vcpu_destroy() unconditionally calls altp2m_vcpu_update_p2m(), which is just a wrapper around vmx_vcpu_update_eptp(). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
Hi guys I have found the problem (after hours and hours of gruesome debugging with the almighty print) and it seems that this could potentially have quite a bit of impact if altp2m is enabled for a guest domain (even if the functionality is never actively used), since destroying any vcpu of this guest could lead to a hypervisor panic. So a malicious user could simply destroy and restart his VM(s) in order to DOS the VMs of other users by killing the hypervisor. Granted, this is not very effective, but, depending on the environment, it is extremely easy to implement. The bug persists in Xen 4.7 and I do not that it was fixed in the current master branch. The following happens. The call void hvm_vcpu_destroy(struct vcpu *v) { hvm_all_ioreq_servers_remove_vcpu(v->domain, v); if ( hvm_altp2m_supported() ) altp2m_vcpu_destroy(v); at some time reaches vmx_vcpu_update_eptp which ends with a vmx_vmcs_exit(v);. There vmx_clear_vmcs(v); -> __vmx_clear_vmcs is called where the current_vmcs is invalidated if the current vmcs in the CPU is the same as virt_to_maddr (v->arch.hvm_vmx->vmcs): __vmpclear(virt_to_maddr(arch_vmx->vmcs)); ( http://www.tptp.cc/mirrors/siyobik.info/instruction/VMCLEAR.html ) To check this assumption I implemented a basic __vmptrst ( http://www.tptp.cc/mirrors/siyobik.info/instruction/VMPTRST.html ) and added the result to the debug output. (XEN) vmcs.c:519:IDLEv4 __vmx_clear_vmcs: realVMCS BEFORE __vmpclear 82415a000 (XEN) vmcs.c:522:IDLEv4 __vmx_clear_vmcs: realVMCS AFTER __vmpclear After that no vmcs_load / enter is executed so the vmcs in the CPU remains invalidated. For the next function in hvm_vcpu_destroy, the nestedhvm_vcpu_destroy(v) the missing vmcs is no problem (at least in our use case), but the free_compat_arg_xlat crashes. The callstack is as follows: hvm_vcpu_destroy free_compat_arg_xlat destroy_perdomain_mapping map_domain_page (probably inlined) mapcache_current_vcpu sync_local_execstate __sync_local_execstate __context_switch (with function pointer v->arch.ctxt_switch_from = vmx_ctxt_switch_from) vmx_ctxt_switch_from (probably inlined) vmx_fpu_leave There a vmwrite is tried if either ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) or ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) ) is true. The executed vmwrite then crashes. As my knowledge of Xen is not that comprehensive, could you tell me when the TS-bits are set / cleared and what they are used for? static void vmx_fpu_leave(struct vcpu *v) { ASSERT(!v->fpu_dirtied); ASSERT(read_cr0() & X86_CR0_TS); if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) { v->arch.hvm_vmx.host_cr0 |= X86_CR0_TS; __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0); } if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) ) { v->arch.hvm_vcpu.hw_cr[0] |= X86_CR0_TS; __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]); v->arch.hvm_vmx.exception_bitmap |= (1u << TRAP_no_device); vmx_update_exception_bitmap(v); } } In the crash dump the additional debug output shows that at least one __vmwrite will be tried and that the VMCS in the CPU is invalidated: (XEN) vmx.c:698:IDLEv4 vmx_fpu_leave: vcpu 8300defae000 vmcs 8301586c9000 host_cr0-case FALSE guest_cr[0]-case TRUE curr 8300df2fb000 curr->arch.hvm_vmx.vmcs realVMCS As a quick fix I patched the fpu_leave to only allow the __vmwrite when the realVMCS is valid. This seems to work fine, but requires a call to __vmptrst every time vmx_fpu_leave is called. Also I do not know if an ignored TS has any negative consequences when destroying a vcpu. I assume that this is not case. In our tests nothing pointed to any problems. I added the patch to enable altp2m unconditionally and a patch which evades the panic in vmx_fpu_leave. They are not pretty or anywhere near production ready, but I think you will get the idea. I tried to implement the __vmptrst with the #ifdef HAVE_GAS_VM parts ( analogue to the other functions in vmx.h ) but failed miserably since I lack the required knowledge about the OPCODE definitions. :-D Cheers Kevin > -Ursprüngliche Nachricht- > Von: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Gesendet: Montag, 22. August 2016 13:58 > An: Mayer, Kevin ; jbeul...@suse.com > Cc: xen-devel@lists.xen.org > Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault > > On 19/08/16 11:01, kevin.ma...@gdata.de wrote: > > Hi > > > > I took another look at Xen and a new crashdump. > > The last successful __vmwrite should be in static void > > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] > > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > > v->arch.hvm_vmx.secondary_exec_control); > > [...] > > After this the altp2m_vcpu_destroy wakes up the vcpu and is then > finished. > > > > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can > overwritten (but is not reached in our case as far as I can see): > >
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
Hi I took the time to write a small script which restores and destroys domains from provided state files. Just apply the patch to a xen 4.6.1, provide some images + state files and start the script. python VmStarter.py -FILE /path/to/domU-0.state -FILE /path/to/domU-1.state --loggingLevel DEBUG You can provide an arbitrary amount of state files and the script will start an additional thread for each one. Each thread restores one guest domain from the provided state file, waits for a random time between 20 and 30 seconds (sleepTime = random.randint(20,30) ) , destroys the domain and then starts the process again. The guest domains and the corresponding state files need to have the same name since the script extracts the domain name from the state file name. When starting about one guest domain for every physical core of the CPU the crash should occur in 5 to 10 minutes. Since the crashes are pretty random the hypervisor sometimes panics almost instantly and sometimes it takes a while, but it seems to correlate with the amount of started guest domains. More domains => faster crash Kevin > -Ursprüngliche Nachricht- > Von: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Gesendet: Montag, 22. August 2016 13:58 > An: Mayer, Kevin ; jbeul...@suse.com > Cc: xen-devel@lists.xen.org > Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault > > On 19/08/16 11:01, kevin.ma...@gdata.de wrote: > > Hi > > > > I took another look at Xen and a new crashdump. > > The last successful __vmwrite should be in static void > > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] > > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > > v->arch.hvm_vmx.secondary_exec_control); > > [...] > > After this the altp2m_vcpu_destroy wakes up the vcpu and is then > finished. > > > > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can > overwritten (but is not reached in our case as far as I can see): > > if ( nvcpu->nv_n1vmcx ) > > v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx; > > > > In conclusion: > > When destroying a domain the altp2m_vcpu_destroy(v); path seems to > mess up the vmcs which ( only ) sometimes leads to a failed __vmwrite in > vmx_fpu_leave. > > That is as far as I can get with my understanding of the Xen code. > > > > Do you guys have any additional ideas what I could test / analyse? > > Do you have easy reproduction instructions you could share? Sadly, this is > looking like an issue which isn't viable to debug over email. > > ~Andrew Virus checked by G Data MailSecurity Version: AVA 25.8183 dated 07.09.2016 Virus news: www.antiviruslab.com xen-altp2menable.patch Description: xen-altp2menable.patch VmStarter.py Description: VmStarter.py ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
Hi The reproduction should be pretty simple: Apply the patch to enable altp2m unconditionally: d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1; d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot; +d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] = 1; + vpic_init(d); rc = vioapic_init(d); For the guest we use one state file ( Windows 10 ) from which the guests are restored with libvirt. Simply restore and destroy several guests (5-7 in our current setup) in fast succession (every guest has about 1-2minutes runtime). The amount of guest-VMs seems to correlate with the time until the crash occurs, but other, random factors seem to be more important. More VMs => the crash happens faster. Is the following debug-setup possible? L0: Xen / VMWare L1: Xen with altp2m enabled L2: Several guest-VMs being constantly restored / destroyed Then periodically take snapshots until the hypervisor panics and try to debug from the latest snapshot on. > -Ursprüngliche Nachricht- > Von: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Gesendet: Montag, 22. August 2016 13:58 > An: Mayer, Kevin ; jbeul...@suse.com > Cc: xen-devel@lists.xen.org > Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault > > On 19/08/16 11:01, kevin.ma...@gdata.de wrote: > > Hi > > > > I took another look at Xen and a new crashdump. > > The last successful __vmwrite should be in static void > > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] > > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > > v->arch.hvm_vmx.secondary_exec_control); > > [...] > > After this the altp2m_vcpu_destroy wakes up the vcpu and is then > finished. > > > > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can > overwritten (but is not reached in our case as far as I can see): > > if ( nvcpu->nv_n1vmcx ) > > v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx; > > > > In conclusion: > > When destroying a domain the altp2m_vcpu_destroy(v); path seems to > mess up the vmcs which ( only ) sometimes leads to a failed __vmwrite in > vmx_fpu_leave. > > That is as far as I can get with my understanding of the Xen code. > > > > Do you guys have any additional ideas what I could test / analyse? > > Do you have easy reproduction instructions you could share? Sadly, this is > looking like an issue which isn't viable to debug over email. > > ~Andrew Virus checked by G Data MailSecurity Version: AVA 25.7981 dated 22.08.2016 Virus news: www.antiviruslab.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
On 19/08/16 11:01, kevin.ma...@gdata.de wrote: > Hi > > I took another look at Xen and a new crashdump. > The last successful __vmwrite should be in > static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v) > [...] > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > v->arch.hvm_vmx.secondary_exec_control); > [...] > After this the altp2m_vcpu_destroy wakes up the vcpu and is then finished. > > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can overwritten (but > is not reached in our case as far as I can see): > if ( nvcpu->nv_n1vmcx ) > v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx; > > In conclusion: > When destroying a domain the altp2m_vcpu_destroy(v); path seems to mess up > the vmcs which ( only ) sometimes leads to a failed __vmwrite in > vmx_fpu_leave. > That is as far as I can get with my understanding of the Xen code. > > Do you guys have any additional ideas what I could test / analyse? Do you have easy reproduction instructions you could share? Sadly, this is looking like an issue which isn't viable to debug over email. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
Hi I took another look at Xen and a new crashdump. The last successful __vmwrite should be in static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...] __vmwrite(SECONDARY_VM_EXEC_CONTROL, v->arch.hvm_vmx.secondary_exec_control); [...] After this the altp2m_vcpu_destroy wakes up the vcpu and is then finished. In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can overwritten (but is not reached in our case as far as I can see): if ( nvcpu->nv_n1vmcx ) v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx; In conclusion: When destroying a domain the altp2m_vcpu_destroy(v); path seems to mess up the vmcs which ( only ) sometimes leads to a failed __vmwrite in vmx_fpu_leave. That is as far as I can get with my understanding of the Xen code. Do you guys have any additional ideas what I could test / analyse? > -Ursprüngliche Nachricht- > Von: Jan Beulich [mailto:jbeul...@suse.com] > Gesendet: Montag, 8. August 2016 12:29 > An: Mayer, Kevin > Cc: andrew.coop...@citrix.com; xen-devel@lists.xen.org > Betreff: Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault > > >>> On 08.08.16 at 11:48, wrote: > > vmx_vmenter_helper is not part of the call stack. The address is > > simply the location of the ud2 to which the __vmwrite(HOST_CR0, > > v->arch.hvm_vmx.host_cr0); In static void vmx_fpu_leave(struct vcpu > > *v) jumps. > > There are two vmwrites in vmx_vcpu_update_eptp (called by > > altp2m_vcpu_destroy): > > __vmwrite(EPT_POINTER, ept_get_eptp(ept)); __vmwrite(EPTP_INDEX, > > vcpu_altp2m(v).p2midx); > > > > And four in vmx_vcpu_update_vmfunc_ve (also called by > > altp2m_vcpu_destroy) __vmwrite(VM_FUNCTION_CONTROL, > > VMX_VMFUNC_EPTP_SWITCHING); __vmwrite(EPTP_LIST_ADDR, > > virt_to_maddr(d->arch.altp2m_eptp)); > > __vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT); > > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > > v->arch.hvm_vmx.secondary_exec_control); > > > > After the altp2m-part hvm_vcpu_destroy also calls > > nestedhvm_vcpu_destroy(v), but this code path is executed > > unconditionally so I assume that the error lies somewhere in the > altp2m_vcpu_destroy(v). > > > > What exactly are the vmx_vmcs_enter / exit required for? I often see > > the vmx_vmcs_enter; __vmwrite; vmx_vmcs_exit combination. Need the > > __vmwrites be guarded by an enter / exit ( which Is not the case in > > the static void vmx_fpu_leave(struct vcpu *v) )? > > On code paths where the correct VMCS may not be the current one it is > necessary to frame vmread / vmwrite accordingly. > > > Is it possible that the > > altp2m_vcpu_destroy->vmx_vcpu_update_eptp->vmx_vmcs_exit- > >vmx_clear_vm > > cs invalidates the vmcs for the current vcpu? > > I certainly can't exclude this possibility. > > Jan Virus checked by G Data MailSecurity Version: AVA 25.7943 dated 19.08.2016 Virus news: www.antiviruslab.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
>>> On 08.08.16 at 11:48, wrote: > vmx_vmenter_helper is not part of the call stack. The address is simply the > location of the ud2 to which the > __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0); > In > static void vmx_fpu_leave(struct vcpu *v) > jumps. > There are two vmwrites in vmx_vcpu_update_eptp (called by > altp2m_vcpu_destroy): > __vmwrite(EPT_POINTER, ept_get_eptp(ept)); > __vmwrite(EPTP_INDEX, vcpu_altp2m(v).p2midx); > > And four in vmx_vcpu_update_vmfunc_ve (also called by altp2m_vcpu_destroy) > __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING); > __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp)); > __vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT); > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > v->arch.hvm_vmx.secondary_exec_control); > > After the altp2m-part hvm_vcpu_destroy also calls nestedhvm_vcpu_destroy(v), > but this code path is executed unconditionally so I assume that the error > lies somewhere in the altp2m_vcpu_destroy(v). > > What exactly are the vmx_vmcs_enter / exit required for? I often see the > vmx_vmcs_enter; __vmwrite; vmx_vmcs_exit combination. Need the __vmwrites be > guarded by an enter / exit ( which Is not the case in the static void > vmx_fpu_leave(struct vcpu *v) )? On code paths where the correct VMCS may not be the current one it is necessary to frame vmread / vmwrite accordingly. > Is it possible that the > altp2m_vcpu_destroy->vmx_vcpu_update_eptp->vmx_vmcs_exit->vmx_clear_vmcs > invalidates the vmcs for the current vcpu? I certainly can't exclude this possibility. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
vmx_vmenter_helper is not part of the call stack. The address is simply the location of the ud2 to which the __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0); In static void vmx_fpu_leave(struct vcpu *v) jumps. There are two vmwrites in vmx_vcpu_update_eptp (called by altp2m_vcpu_destroy): __vmwrite(EPT_POINTER, ept_get_eptp(ept)); __vmwrite(EPTP_INDEX, vcpu_altp2m(v).p2midx); And four in vmx_vcpu_update_vmfunc_ve (also called by altp2m_vcpu_destroy) __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING); __vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp)); __vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT); __vmwrite(SECONDARY_VM_EXEC_CONTROL, v->arch.hvm_vmx.secondary_exec_control); After the altp2m-part hvm_vcpu_destroy also calls nestedhvm_vcpu_destroy(v), but this code path is executed unconditionally so I assume that the error lies somewhere in the altp2m_vcpu_destroy(v). What exactly are the vmx_vmcs_enter / exit required for? I often see the vmx_vmcs_enter; __vmwrite; vmx_vmcs_exit combination. Need the __vmwrites be guarded by an enter / exit ( which Is not the case in the static void vmx_fpu_leave(struct vcpu *v) )? Is it possible that the altp2m_vcpu_destroy->vmx_vcpu_update_eptp->vmx_vmcs_exit->vmx_clear_vmcs invalidates the vmcs for the current vcpu? Cheers Kevin > -Ursprüngliche Nachricht- > Von: Jan Beulich [mailto:jbeul...@suse.com] > Gesendet: Freitag, 5. August 2016 16:49 > An: Mayer, Kevin > Cc: andrew.coop...@citrix.com; xen-devel@lists.xen.org > Betreff: Re: AW: AW: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabled > bydefault > > >>> On 05.08.16 at 14:51, wrote: > > According to the xen dmesg > > > > (XEN) RIP:e008:[] > vmx_vmenter_helper+0x27e/0x30a > > (XEN) RFLAGS: 00010003 CONTEXT: hypervisor > > (XEN) rax: 8005003b rbx: 8300e72fc000 rcx: > > > (XEN) rdx: 6c00 rsi: 830617fd7fc0 rdi: 8300e6fc > > (XEN) rbp: 830617fd7c40 rsp: 830617fd7c30 r8: > > (XEN) r9: 830be8dc9310 r10: r11: 3475e9cf85d0 > > (XEN) r12: 0006 r13: 830c14ee1000 r14: 8300e6fc > > (XEN) r15: 830617fd cr0: 8005003b cr4: > 26e0 > > (XEN) cr3: 0001bd665000 cr2: 0451 > > (XEN) ds: es: fs: gs: ss: cs: e008 > > > > 0x82d0801fa0c3 :mov$0x6c00,%edx > > 0x82d0801fa0c8 :vmwrite %rax,%rdx > > > > The vmwrite tries to write 0x8005003b to 0x6c00. > > But the active VCPU has a 0-vmcs-pointer. > > Which likely means altp2m manages to confuse some of VMX'es VMCS > management - vmx_vmenter_helper() being on the path back to the guest, > it should be impossible for the VMCS pointer to be zero here. Can you > perhaps identify the most recent vmread or vmwrite which worked fine? > There ought to be many on that path, and the state corruption could then > perhaps be narrowed to quite small a range of code. > > Jan Virus checked by G Data MailSecurity Version: AVA 25.7794 dated 08.08.2016 Virus news: www.antiviruslab.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel