On Fri, Oct 04, 2024 at 08:52:52AM +0200, Jan Beulich wrote:
> On 03.10.2024 01:20, Andrew Cooper wrote:
> > The logic would be more robust disabling SMAP based on its precense in CR4,
> > rather than SMAP's accociation with a synthetic feature.
>
> It's hard to tell what's more robust without knowing what future changes
> there might be. In particular ...
>
> > @@ -1064,19 +1065,19 @@ int __init dom0_construct_pv(struct domain *d,
> > * prevents us needing to write construct_dom0() in terms of
> > * copy_{to,from}_user().
> > */
> > - if ( boot_cpu_has(X86_FEATURE_XEN_SMAP) )
> > + if ( cr4 & X86_CR4_SMAP )
>
> ... with this adjustment ...
>
> > {
> > if ( IS_ENABLED(CONFIG_PV32) )
> > cr4_pv32_mask &= ~X86_CR4_SMAP;
>
> ... this update of a global no longer occurs. Playing games with CR4
> elsewhere might run into issues with this lack of updating.
Maybe we should assert the state of cr4 is as expected?
ASSERT(!boot_cpu_has(X86_FEATURE_XEN_SMAP) || (cr4 & X86_CR4_SMAP));
Thanks, Roger.
