[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: introduce and use setup_force_cpu_cap()



>>> Sarah Newman <srn@xxxxxxxxx> 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 <security@xxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
>Reported-by/Tested-by: Sarah Newman <srn@xxxxxxxxx>

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.