All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Julien Grall <julien.grall@arm.com>,
	andre.przywara@arm.com
Subject: Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
Date: Wed, 23 May 2018 17:48:16 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1805231741550.23229@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <alpine.DEB.2.10.1805231504320.15101@sstabellini-ThinkPad-X260>

On Wed, 23 May 2018, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> > useful to either permanently enable or disable the workaround for cases
> > where the user decides that they'd rather not get a trap overhead, and
> > keep the mitigation permanently on or off instead of switching it on
> > exception entry/exit.
> > 
> > In any case, default to mitigation being enabled.
> > 
> > At the same time provide a accessor to know the state of the mitigation.
> > 
> > SIgned-off-by: Julien Grall <julien.grall@arm.com>
> > ---
> >  docs/misc/xen-command-line.markdown |  18 ++++++
> >  xen/arch/arm/cpuerrata.c            | 115 ++++++++++++++++++++++++++++++++----
> >  xen/include/asm-arm/cpuerrata.h     |  21 +++++++
> >  xen/include/asm-arm/smccc.h         |   1 +
> >  4 files changed, 144 insertions(+), 11 deletions(-)
> > 
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> > index 8712a833a2..962028b6ed 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 670ms. Any number
> >  is being interpreted as a custom timeout in milliseconds. Zero or boolean
> >  false disable the quirk workaround, which is also the default.
> >  
> > +### spec-ctrl (Arm)
> > +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
> 
> Why a list? Shouldn't it be one or the other?
> 
> > +Controls for speculative execution sidechannel mitigations.
> > +
> > +The option `ssbd=` is used to control the state of Speculative Store
> > +Bypass Disable (SSBD) mitigation.
> > +
> > +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
> > +will not be able to control the state of the mitigation.
> > +* `ssbd=runtime` will always turn on the mitigation when running in the
> > +hypervisor context. The guest will be to turn on/off the mitigation for
> > +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> > +* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
> > +not be able to control the state of the mitigation.
> > +
> > +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> > +
> >  ### spec-ctrl (x86)
> >  > `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> >  >              bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool> ]`
> > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > index bcea2eb6e5..f921721a66 100644
> > --- a/xen/arch/arm/cpuerrata.c
> > +++ b/xen/arch/arm/cpuerrata.c
> > @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
> >  
> >  #ifdef CONFIG_ARM_SSBD
> >  
> > +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> > +
> > +static int __init parse_spec_ctrl(const char *s)
> > +{
> > +    const char *ss;
> > +    int rc = 0;
> > +
> > +    do {
> > +        ss = strchr(s, ',');
> > +        if ( !ss )
> > +            ss = strchr(s, '\0');
> 
> It doesn't look like it is necessary to parse ',' at all. I would remove
> the while loop too.
> 
> 
> > +        if ( !strncmp(s, "ssbd=", 5) )
> > +        {
> > +            s += 5;
> > +
> > +            if ( !strncmp(s, "force-disable", ss - s) )
> > +                ssbd_state = ARM_SSBD_FORCE_DISABLE;
> > +            else if ( !strncmp(s, "runtime", ss - s) )
> > +                ssbd_state = ARM_SSBD_RUNTIME;
> > +            else if ( !strncmp(s, "force-enable", ss - s) )
> > +                ssbd_state = ARM_SSBD_FORCE_ENABLE;
> > +            else
> > +                rc = -EINVAL;
> > +        }
> > +        else
> > +            rc = -EINVAL;
> > +
> > +        s = ss + 1;
> > +    } while ( *ss );
> > +
> > +    return rc;
> > +}
> > +custom_param("spec-ctrl", parse_spec_ctrl);
> > +
> >  /*
> >   * Assembly code may use the variable directly, so we need to make sure
> >   * it fits in a register.
> > @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> >  static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> >  {
> >      struct arm_smccc_res res;
> > -    bool supported = true;
> > +    bool required = true;
> 
> Please avoid this renaming. Choose one name or the other from the start.
> 
> 
> >      if ( smccc_ver < SMCCC_VERSION(1, 1) )
> >          return false;
> >  
> > -    /*
> > -     * The probe function return value is either negative (unsupported
> > -     * or mitigated), positive (unaffected), or zero (requires
> > -     * mitigation). We only need to do anything in the last case.
> > -     */
> 
> I would keep the comment
> 
> 
> >      arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> >                        ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > -    if ( (int)res.a0 != 0 )
> > -        supported = false;
> >  
> > -    if ( supported )
> > -        this_cpu(ssbd_callback_required) = 1;
> > +    switch ( (int)res.a0 )
> 
> Please introduce this switch in the previous patch. But it makes sense
> to add the ssbd_state variable in this patch.
> 
> 
> > +    {
> > +    case ARM_SMCCC_NOT_SUPPORTED:
> > +        ssbd_state = ARM_SSBD_UNKNOWN;
> > +        return false;
> > +
> > +    case ARM_SMCCC_NOT_REQUIRED:
> > +        ssbd_state = ARM_SSBD_MITIGATED;
> > +        return false;
> > +
> > +    case ARM_SMCCC_SUCCESS:
> > +        required = true;
> > +        break;
> > +
> > +    case 1: /* Mitigation not required on this CPU. */
> > +        required = false;
> > +        break;
> 
> This should "return false". Also, it might make sense to set ssbd_state
> to ARM_SSBD_MITIGATED?
> 
> 
> > +
> > +    default:
> > +        ASSERT_UNREACHABLE();
> > +        return false;
> > +    }
> > +
> > +    switch ( ssbd_state )
> > +    {
> > +    case ARM_SSBD_FORCE_DISABLE:
> > +    {
> > +        static bool once = true;
> > +
> > +        if ( once )
> > +            printk("%s disabled from command-line\n", entry->desc);
> > +        once = false;
> > +
> > +        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > +        required = false;
> > +
> > +        break;
> > +    }
> > +
> > +    case ARM_SSBD_RUNTIME:
> > +        if ( required )
> > +        {
> > +            this_cpu(ssbd_callback_required) = 1;
> 
> We have the ARM_SSBD bit, the ssbd_state variable and
> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> cores while ssbd_callback_required is per-cpu. Does
> ssbd_callback_required really need to be per-cpu? Do we need both
> variables? For instance, we could just return ssbd_state ==
> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?

After reading the whole series, I think ssbd_state should be a per_cpu
variable. parse_spec_ctrl initializes ssbd_state to the same value on
all cpus. has_ssbd_mitigation modifies ssbd_state only on the CPUs it is
running on. We get rid of ssbd_callback_required. The assembly fast past
reads ssbd_state instead of ssbd_callback_required.

What do you think?


 
> > +            arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > +        }
> > +
> > +        break;
> > +
> > +    case ARM_SSBD_FORCE_ENABLE:
> > +    {
> > +        static bool once = true;
> > +
> > +        if ( once )
> > +            printk("%s forced from command-line\n", entry->desc);
> > +        once = false;
> > +
> > +        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > +        required = true;
> 
> This function is supposed to detect whether a workaround is needed, not
> enable it, right? Should this switch and relative code be moved to the
> .enable function for this capability?
> 
> 
> > +        break;
> > +    }
> > +
> > +    default:
> > +        ASSERT_UNREACHABLE();
> > +        return false;
> > +    }
> >  
> > -    return supported;
> > +    return required;
> >  }
> >  #endif
> >  
> > @@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> >  #endif
> >  #ifdef CONFIG_ARM_SSBD
> >      {
> > +        .desc = "Speculative Store Bypass Disabled",
> >          .capability = ARM_SSBD,
> >          .matches = has_ssbd_mitigation,
> >      },
> > diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> > index e628d3ff56..7fbb3dc0be 100644
> > --- a/xen/include/asm-arm/cpuerrata.h
> > +++ b/xen/include/asm-arm/cpuerrata.h
> > @@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
> >  
> >  #undef CHECK_WORKAROUND_HELPER
> >  
> > +enum ssbd_state
> > +{
> > +    ARM_SSBD_UNKNOWN,
> > +    ARM_SSBD_FORCE_DISABLE,
> > +    ARM_SSBD_RUNTIME,
> > +    ARM_SSBD_FORCE_ENABLE,
> > +    ARM_SSBD_MITIGATED,
> > +};
> > +
> >  #ifdef CONFIG_ARM_SSBD
> >  
> >  #include <asm/current.h>
> >  
> > +extern enum ssbd_state ssbd_state;
> > +
> > +static inline enum ssbd_state get_ssbd_state(void)
> > +{
> > +    return ssbd_state;
> > +}
> > +
> >  DECLARE_PER_CPU(register_t, ssbd_callback_required);
> >  
> >  static inline bool cpu_require_ssbd_mitigation(void)
> > @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
> >      return false;
> >  }
> >  
> > +static inline enum ssbd_state get_sbdd_state(void)
> > +{
> > +    return ARM_SSBD_UNKNOWN;
> > +}
> > +
> >  #endif
> >  
> >  #endif /* __ARM_CPUERRATA_H__ */
> > diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> > index 650744d28b..a6804cec99 100644
> > --- a/xen/include/asm-arm/smccc.h
> > +++ b/xen/include/asm-arm/smccc.h
> > @@ -265,6 +265,7 @@ struct arm_smccc_res {
> >                         0x7FFF)
> >  
> >  /* SMCCC error codes */
> > +#define ARM_SMCCC_NOT_REQUIRED          (-2)
> >  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
> >  #define ARM_SMCCC_NOT_SUPPORTED         (-1)
> >  #define ARM_SMCCC_SUCCESS               (0)
> > -- 
> > 2.11.0
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-05-24  0:48 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
2018-05-22 17:42 ` [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack Julien Grall
2018-05-25 20:52   ` Stefano Stabellini
2018-05-29 10:27     ` Julien Grall
2018-05-29 21:41       ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync Julien Grall
2018-05-23 21:27   ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on Julien Grall
2018-05-23 21:34   ` Stefano Stabellini
2018-05-25 19:51     ` Julien Grall
2018-05-29 21:30       ` Stefano Stabellini
2018-05-30  9:17         ` Julien Grall
2018-05-22 17:42 ` [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing Julien Grall
2018-05-23 21:57   ` Stefano Stabellini
2018-05-23 22:31     ` Julien Grall
2018-05-25 20:51       ` Stefano Stabellini
2018-05-25 23:54         ` Andrew Cooper
2018-05-29 21:35           ` Stefano Stabellini
2018-05-30  9:35             ` Julien Grall
2018-05-22 17:42 ` [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation Julien Grall
2018-05-23 22:34   ` Stefano Stabellini
2018-05-24  0:48     ` Stefano Stabellini [this message]
2018-05-25 19:56       ` Julien Grall
2018-05-24  9:52     ` Julien Grall
2018-05-25 20:51       ` Stefano Stabellini
2018-05-29 11:31         ` Julien Grall
2018-05-29 22:34           ` Stefano Stabellini
2018-05-30 10:39             ` Julien Grall
2018-05-30 20:10               ` Stefano Stabellini
2018-05-31 10:34                 ` Julien Grall
2018-05-31 20:58                   ` Stefano Stabellini
2018-05-31 21:29                     ` Julien Grall
2018-05-23 23:23   ` Stefano Stabellini
2018-05-24  9:53     ` Julien Grall
2018-05-22 17:42 ` [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests Julien Grall
2018-05-23 23:24   ` Stefano Stabellini
2018-05-24  0:40     ` Stefano Stabellini
2018-05-24 10:00       ` Julien Grall
2018-05-25 20:51         ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 07/13] xen/arm: Simplify alternative patching Julien Grall
2018-05-25 20:52   ` Stefano Stabellini
2018-05-25 21:34     ` Julien Grall
2018-05-25 23:24       ` Stefano Stabellini
2018-05-29 11:34         ` Julien Grall
2018-05-22 17:42 ` [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature Julien Grall
2018-05-25 20:52   ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 09/13] xen/arm64: Add generic assembly macros Julien Grall
2018-05-23 23:37   ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2 Julien Grall
2018-05-25 19:18   ` Stefano Stabellini
2018-05-29 12:16     ` Julien Grall
2018-05-29 21:39       ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features" Julien Grall
2018-05-23 23:45   ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID Julien Grall
2018-05-23 23:44   ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head Julien Grall
2018-05-23 23:47   ` Stefano Stabellini
2018-05-24 10:29     ` Julien Grall
2018-05-24 18:46       ` Stefano Stabellini
2018-05-22 17:46 ` [for-4.11] Re: [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
2018-05-23  4:07   ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1805231741550.23229@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=julien.grall@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.