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

Reply via email to