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