Re: [Xen-devel] [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 02/29/2016 06:50 PM, Andy Lutomirski wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 91ddae732a36..c6ef4da8e4f4 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -979,6 +979,31 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>   #ifdef CONFIG_NUMA
>         numa_add_cpu(smp_processor_id());
>   #endif
> +
> +       /*
> +        * ESPFIX is a strange bug.  All real CPUs have it.  Paravirt
> +        * systems that run Linux at CPL > 0 may or may not have the
> +        * issue, but, even if they have the issue, there's absolutely
> +        * nothing we can do about it because we can't use the real IRET
> +        * instruction.
> +        *
> +        * NB: For the time being, only 32-bit kernels support
> +        * X86_BUG_ESPFIX as such.  64-bit kernels directly choose
> +        * whether to apply espfix using paravirt hooks.  If any
> +        * non-paravirt system ever shows up that does *not* have the
> +        * ESPFIX issue, we can change this.
> +        */
> +#ifdef CONFIG_X86_32
> +#ifdef CONFIG_PARAVIRT
> +       do {
> +               extern void native_iret(void);
> +               if (pv_cpu_ops.iret == native_iret)
> +                       set_cpu_bug(c, X86_BUG_ESPFIX);
> +       } while (0);
> +#else
> +       set_cpu_bug(c, X86_BUG_ESPFIX);
> +#endif
> +#endif
>   }
>   
>   /*

Alternatively, PV guests can clear X86_BUG_ESPFIX in their init code. 
E.g in .set_cpu_features op, just like we do for X86_BUG_SYSRET_SS_ATTRS 
(although this may require adding struct hypervisor_x86 for lguests. 
Which I think they should have anyway).
-boris

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