[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] nested vmx: Intercept guest rdmsr for MSR_IA32_VMX_VMFUNC



>>> On 07.06.16 at 12:18, <euan.harris@xxxxxxxxxx> wrote:
> Guest reads of MSR_IA32_VMX_VMFUNC should be handled by
> the logic in vmx_msr_read_intercept().   Otherwise a guest
> can read the raw host value of this MSR, even if nested
> vmx is disabled.
> 
> Signed-off-by: Euan Harris <euan.harris@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Albeit ...

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, 
> uint64_t *msr_content)
>          __vmread(GUEST_IA32_DEBUGCTL, msr_content);
>          break;
>      case IA32_FEATURE_CONTROL_MSR:
> -    case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS:
> +    case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC:
>          if ( !nvmx_msr_read_intercept(msr, msr_content) )
>              goto gp_fault;
>          break;

... retaining this code structure makes it likely that some future
addition will lead to the same problem again. I think there should
be something like MSR_IA32_VMX_LAST added to msr-index.h,
and get used here instead. Suitably placed it would make pretty
obvious to someone adding a new MSR there that this value also
needs updating.

Or alternatively: Is there an architectural upper bound to the
VMX MSR range? If so, we could widen the set to the full range
in one go.

VMX maintainers - I'd appreciate if you could take care of this in
one way or another.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.