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

[Jan Beulich <jbeulich@suse.com>]

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