Re: [PATCH 2/4] x86: reduce CET-SS related #ifdef-ary

[Andrew Cooper <andrew.cooper3@citrix.com>]

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 <jbeulich@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