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