Re: [PATCH v1 1/2] x86/vvmx: check vmcs address in vmread/vmwrite

[Sergey Dyasli <sergey.dyasli@citrix.com>]

On Wed, 2017-03-01 at 07:28 -0700, Jan Beulich wrote:
> > > > On 01.03.17 at 15:22, <sergey.dyasli@citrix.com> wrote:
> > 
> > On Wed, 2017-03-01 at 07:04 -0700, Jan Beulich wrote:
> > > > > > On 01.03.17 at 14:44, <sergey.dyasli@citrix.com> wrote:
> > > > 
> > > > Additionally, it would be painful to return the correct error value
> > > > all the way back to nvmx_handle_vmptrld().
> > > 
> > > Surely that's at best relevant in the other patch. Here you're in
> > > virtual_vmcs_vmwrite_safe(), which already knows how to
> > > communicate back an error indicator.
> > 
> > How checking the return value of virtual_vmcs_enter() is different
> > from checking nv_vvmcxaddr?
> 
> Checking the address is just one step. As the other patch shows,
> checking the ID is necessary too. Over time more such checks may
> be found necessary. Checking what hardware hands us is a single
> check, and is always going to be sufficient no matter what new
> features get added to hardware.

Conceptually, the result of __vmptrld() is irrelevant to a guest
during nested vmread/vmwrite emulation.  The fact that Xen is doing
__vmptrld() is a side effect of nested VMX.

All necessary checks may be found in Intel SDM.  And it states that
there can be only 1 VMfail if VMCS pointer is not valid: VMfailInvalid.
vmptrld can end up in 3 different VMfails and returning them to the
guest as a result of vmread/vmwrite emulation is wrong.

(Even though each of them will end up being VMfailInvalid in current
implementation)

I think that Xen's goal in nested VMX is emulating H/W as close as
possible.

-- 
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel