>>> Sarah Newman <s...@prgmr.com> 09/07/17 3:55 AM >>> >On 09/05/2017 06:22 AM, Jan Beulich wrote: >> For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd >> need to clone the respective hack used for CPUID_FAULTING. Introduce an >> inverse of setup_clear_cpu_cap() instead, but let clearing of features >> overrule forced setting of them. >> >> XEN_SMAP being wrong post-boot is a problem specifically for live >> patching, as a live patch may need alternative instruction patching >> keyed off of that feature flag. >> >> Reported-by: Sarah Newman <secur...@prgmr.com> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > >Reported-by/Tested-by: Sarah Newman <s...@prgmr.com>
Thanks. >Some questions: > >It looks like setup_clear_cpu_cap has a search for dependent capabilities >that also must be cleared. Does the same need to happen for >setup_force_cpu_cap even if it doesn't matter for the current cpu features? We obviously can't force-set dependent capabilities, and forcing a feature on won't result in the need to clear any others (unless of course it was a strange inverse "feature", but for those it would probably be better to not force them on in the first place). >Does it make sense to add a comment where forced_caps is declared >that cleared_caps overrides forced_caps instead of just in the commit >message? From the code it should be pretty obvious, I would think. But of course you're free to submit a patch to add comments if you feel strongly about it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
