On 26/07/2024 4:21 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index eee20bb1753c..bc387d96b519 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -955,26 +955,9 @@ static struct domain *__init create_dom0(const module_t 
> *image,
>          }
>      }
>  
> -    /*
> -     * Temporarily clear SMAP in CR4 to allow user-accesses in 
> construct_dom0().
> -     * This saves a large number of corner cases interactions with
> -     * copy_from_user().
> -     */
> -    if ( cpu_has_smap )
> -    {
> -        cr4_pv32_mask &= ~X86_CR4_SMAP;
> -        write_cr4(read_cr4() & ~X86_CR4_SMAP);
> -    }
> -
>      if ( construct_dom0(d, image, headroom, initrd, cmdline) != 0 )
>          panic("Could not construct domain 0\n");
>  
> -    if ( cpu_has_smap )
> -    {
> -        write_cr4(read_cr4() | X86_CR4_SMAP);
> -        cr4_pv32_mask |= X86_CR4_SMAP;
> -    }
> -

Hang on.  Isn't this (preexistingly) broken given the distinction
between cpu_has_smap and X86_FEATURE_XEN_SMAP ?

I'm very tempted to use this as a justification to remove opt_smap.

~Andrew

Reply via email to