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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.07.2020 16:29, Andrew Cooper wrote:
> On 15/07/2020 11:48, Jan Beulich wrote:
> > 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.
Complexity: Yes. Zero value - surely not. I'm having a hard time seeing
why you may think so. Would you mind explaining yourself?

>   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.
One is better than nothing, but still pretty little.

> > --- 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.
Neither do I. Then we'd also switch STAC/CLAC to MAYBE_STAC / MAYBE_CLAC.

> The think is that everything present there is semantically relevant
> information, and dropping it makes the code worse rather than better.
Everything? I don't see why the #ifdef-s are semantically relevant
(the needed infor is already conveyed by the ALTERNATIVE and its
arguments). I consider them primarily harming readability, and thus I
think we should strive to eliminate them if we can. Hence this patch
...

Jan