Re: [Xen-devel] Blocking CR and MSR writes via mem_access?

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

> I've actually been looking at this for a bit, and while it's true that
> it might work for CR events, it's less clear how that would work for MSRs.
> 
> The CR part might be done in the following fashion:
> 
> vcpu_guest_context_any_t ctx;
> 
> if (xc_vcpu_getcontext(xch, domain, req.vcpu_id, &ctx) == 0) {
>       ctx.c.ctrlreg[crNumber] = req.gla; /* old value */
>       xc_vcpu_setcontext(xch, domain, req.vcpu_id, &ctx);
> }

Coming back to this, testing showed that the values were indeed _not_
written. Looking at the code, we end up in arch_set_info_guest() in
xen/arch/x86/domain.c, which does a few things and then, for HVM guests,
calls hvm_set_info_guest() and pretty much exits:

 741     if ( is_hvm_vcpu(v) )
 742     {
 743         hvm_set_info_guest(v);
 744         goto out;
 745     }

In the VMX case, this doesn't do much (it definitely doesn't set any CR
registers):

1542 static void vmx_set_info_guest(struct vcpu *v)
1543 {
1544     unsigned long intr_shadow;
1545
1546     vmx_vmcs_enter(v);
1547
1548     __vmwrite(GUEST_DR7, v->arch.debugreg[7]);
1549
1550     /*
1551      * If the interruptibility-state field indicates blocking by STI,
1552      * setting the TF flag in the EFLAGS may cause VM entry to fail
1553      * and crash the guest. See SDM 3B 22.3.1.5.
1554      * Resetting the VMX_INTR_SHADOW_STI flag looks hackish but
1555      * to set the GUEST_PENDING_DBG_EXCEPTIONS.BS here incurs
1556      * immediately vmexit and hence make no progress.
1557      */
1558     __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
1559     if ( v->domain->debugger_attached &&
1560          (v->arch.user_regs.eflags & X86_EFLAGS_TF) &&
1561          (intr_shadow & VMX_INTR_SHADOW_STI) )
1562     {
1563         intr_shadow &= ~VMX_INTR_SHADOW_STI;
1564         __vmwrite(GUEST_INTERRUPTIBILITY_INFO, intr_shadow);
1565     }
1566
1567     vmx_vmcs_exit(v);
1568 }

Hope this helps others considering going down this road.


Regards,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel