Re: [Xen-devel] [PATCH 5/9] x86/HVM: refuse CR3 loads with reserved (upper) bits set

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Sep 11, 2019 at 05:24:41PM +0200, Jan Beulich wrote:
> While bits 11 and below are, if not used for other purposes, reserved
> but ignored, bits beyond physical address width are supposed to raise
> exceptions (at least in the non-nested case; I'm not convinced the
> current nested SVM/VMX behavior of raising #GP(0) here is correct, but
> that's not the subject of this change).
> 
> Introduce currd as a local variable, and replace other v->domain
> instances at the same time.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

LGTM, just two comments which are not related to functionality, so:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1004,6 +1004,13 @@ static int hvm_load_cpu_ctxt(struct doma
>          return -EINVAL;
>      }
>  
> +    if ( ctxt.cr3 & ~((1UL << d->arch.cpuid->extd.maxphysaddr) - 1) )
> +    {
> +        printk(XENLOG_G_ERR "HVM%d restore: bad CR3 %#" PRIx64 "\n",

gprintk would be more natural here IMO.

> +               d->domain_id, ctxt.cr3);
> +        return X86EMUL_EXCEPTION;
> +    }
> +
>      if ( (ctxt.flags & ~XEN_X86_FPU_INITIALISED) != 0 )
>      {
>          gprintk(XENLOG_ERR, "bad flags value in CPU context: %#x\n",
> @@ -2290,10 +2297,19 @@ int hvm_set_cr0(unsigned long value, boo
>  int hvm_set_cr3(unsigned long value, bool noflush, bool may_defer)
>  {
>      struct vcpu *v = current;
> +    struct domain *currd = v->domain;
>      struct page_info *page;
>      unsigned long old = v->arch.hvm.guest_cr[3];
>  
> -    if ( may_defer && unlikely(v->domain->arch.monitor.write_ctrlreg_enabled 
> &
> +    if ( value & ~((1UL << currd->arch.cpuid->extd.maxphysaddr) - 1) )

I would consider introducing a macro/inline helper for this, since
it's already used twice in this patch.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel