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

Re: [Xen-devel] [PATCH] VMX: XSA-60 workaround



On Tue, Aug 13, 2013 at 05:36:17PM +0100, Jan Beulich wrote:
> Considering that there's still no real progress towards a resolution
> for XSA-60, I'd like to propose turning off the probelamtic code by
> default, allowing it to be turned back on via command line option.

Apologies for a late reply, I've been on holiday for the past week.

I think it'd be really handy to make this a per-domain configuration,
perhaps with a system-wide default set by boot command line. If not
per-domain, it would be helpful to be configurable at boot time.

--msw

> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -57,6 +57,14 @@
>  #include <asm/hvm/nestedhvm.h>
>  #include <asm/event.h>
>  
> +/*
> + * Option to allow VMX guests to run with caches disabled. This is exposing
> + * the host to DoS attacks (due to the way vmx_set_uc_mode() works), and 
> hence
> + * needs to be disabled by default.
> + */
> +static bool_t __read_mostly opt_permit_cache_disable;
> +boolean_param("vmx-permit-cache-disable", opt_permit_cache_disable);
> +
>  enum handler_return { HNDL_done, HNDL_unhandled, HNDL_exception_raised };
>  
>  static void vmx_ctxt_switch_from(struct vcpu *v);
> @@ -1133,6 +1141,8 @@ static void vmx_update_guest_cr(struct v
>  
>          v->arch.hvm_vcpu.hw_cr[0] =
>              v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
> +        if ( !opt_permit_cache_disable )
> +            v->arch.hvm_vcpu.hw_cr[0] &= ~(X86_CR0_CD | X86_CR0_NW);
>          __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
>          __vmwrite(CR0_READ_SHADOW, v->arch.hvm_vcpu.guest_cr[0]);
>  
> @@ -1603,6 +1613,9 @@ const struct hvm_function_table * __init
>          vmx_function_table.sync_pir_to_irr = NULL;
>      }
>  
> +    if ( !opt_permit_cache_disable )
> +        vmx_function_table.set_uc_mode = NULL;
> +
>      setup_vmcs_dump();
>  
>      return &vmx_function_table;
> 
> 
> 

> VMX: XSA-60 workaround
> 
> Considering that there's still no real progress towards a resolution
> for XSA-60, I'd like to propose turning off the probelamtic code by
> default, allowing it to be turned back on via command line option.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -57,6 +57,14 @@
>  #include <asm/hvm/nestedhvm.h>
>  #include <asm/event.h>
>  
> +/*
> + * Option to allow VMX guests to run with caches disabled. This is exposing
> + * the host to DoS attacks (due to the way vmx_set_uc_mode() works), and 
> hence
> + * needs to be disabled by default.
> + */
> +static bool_t __read_mostly opt_permit_cache_disable;
> +boolean_param("vmx-permit-cache-disable", opt_permit_cache_disable);
> +
>  enum handler_return { HNDL_done, HNDL_unhandled, HNDL_exception_raised };
>  
>  static void vmx_ctxt_switch_from(struct vcpu *v);
> @@ -1133,6 +1141,8 @@ static void vmx_update_guest_cr(struct v
>  
>          v->arch.hvm_vcpu.hw_cr[0] =
>              v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
> +        if ( !opt_permit_cache_disable )
> +            v->arch.hvm_vcpu.hw_cr[0] &= ~(X86_CR0_CD | X86_CR0_NW);
>          __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
>          __vmwrite(CR0_READ_SHADOW, v->arch.hvm_vcpu.guest_cr[0]);
>  
> @@ -1603,6 +1613,9 @@ const struct hvm_function_table * __init
>          vmx_function_table.sync_pir_to_irr = NULL;
>      }
>  
> +    if ( !opt_permit_cache_disable )
> +        vmx_function_table.set_uc_mode = NULL;
> +
>      setup_vmcs_dump();
>  
>      return &vmx_function_table;

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


_______________________________________________
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®.