On 15/07/2020 11:48, Jan Beulich wrote:
> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
> to introduce a number of #ifdef-s to make the build work with older tool
> chains. Introduce an assembler macro covering for tool chains not
> knowing of CET-SS, allowing some conditionals where just SETSSBSY is the
> problem to be dropped again.
>
> No change to generated code.> > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > Now that I've done this I'm not longer sure which direction is better to > follow: On one hand this introduces dead code (even if just NOPs) into > CET-SS-disabled builds. Otoh this is a step towards breaking the tool > chain version dependency of the feature. The toolchain dependency can't be broken, because of incssp and wrss in C. There is 0 value and added complexity to trying to partially support legacy toolchains. Furthermore, this adds a pile of nops into builds which have specifically opted out of CONFIG_XEN_SHSTK, which isn't ideal for embedded usecases. As a consequence, I think its better to keep things consistent with how they are now. One thing I already considered was to make cpu_has_xen_shstk return false for !CONFIG_XEN_SHSTK, which subsumes at least one hunk in this change. > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -198,9 +198,7 @@ ENTRY(cr4_pv32_restore) > > /* See lstar_enter for entry register state. */ > ENTRY(cstar_enter) > -#ifdef CONFIG_XEN_SHSTK > ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK > -#endif I can't currently think of any option better than leaving these ifdef's in place, other than perhaps #ifdef CONFIG_XEN_SHSTK # define MAYBE_SETSSBSY ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK #else # define MAYBE_SETSSBSY #endif and I don't like it much. The think is that everything present there is semantically relevant information, and dropping it makes the code worse rather than better. ~Andrew
