Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Jan Beulich]

>>> 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

[Kevin.Mayer]

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 <kevin.ma...@gdata.de>; 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_vcp

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Kevin.Mayer]

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 <kevin.ma...@gdata.de>; 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

[Kevin.Mayer]

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 <kevin.ma...@gdata.de>; 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

[Andrew Cooper]

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

[Kevin.Mayer]

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 <kevin.ma...@gdata.de>
> 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, <kevin.ma...@gdata.de> 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

[Jan Beulich]

>>> 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

[Kevin.Mayer]

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